The cool thing about the CL community is how by simply joining #commonlisp on libera.chat, you are in the same room as a bunch of compiler designers and even people who were involved at one point in the CL specification itself.
I have some interesting IRC logs from Larry Masinter on reviving Interlisp, some regrets about including LOOP into Common Lisp, and so on.
How strange, I met Larry about two decades ago at a research conference and we stayed in touch by email for a little while. I had no idea he was this prominent or influential, and he never mentioned anything other than his current work. Super good guy, very kind to a grad student who was a nobody in the world.
> 2:26:37
masinter i tell people that my greatest contribution to the Common Lisp standard was inventing the form you had to fill out to get a change to the language passed in the cleanup committee
> 2:27:31
masinter where you had to list the problem you were solving without making reference to your solution
That's really great. Decoupling problems from solutions is often the only way for discussion to move forward.
Very much in the same spirit is Kent Pitman reflecting on the value of the charter [2] for the X3J13 standardization committee [1]:
5.3 Charter: Susan Ennis (1986)
Sitting in a room for a good part of a meeting coming up with words to write as part of our mission did not seem like a good use of time to me at that moment. But I went along with it because there seemed no stopping it. In retrospect, I consider this a major administrative contribution and I credit the committee chair, Susan Ennis, for getting us to do it.
What I found later was that there were many times during work on the standard where people disagreed about what the right way to proceed was. In many of those cases, we might have been hopelessly deadlocked, each wanting to pursue a different agenda, but I was able instead to point to the charter and say, “No, we agreed that this is how we’d resolve things like this.”
...
The time spent writing the charter later paid for itself many times over and it’s an exercise I recommend to any committee engaged in any large endeavor over a period of time.
Edit: I just noticed that the very next section, 5.4 Cleanup: Larry Masinter, discusses this very point about forms
I found his remarks about how (modern, ML-based) AI is the winter for Lisp interesting and congruent with how I see things currently. At the end of the day, many of the hardest problems in computing are solved best by simply throwing more compute (esp. matrix and array), memory, and data at them. Today's Lisp machines are GPGPU.
I've been surviving a winter of my own since 1997 when video cards took over and Moore's Law for CPUs started slowing down, finally ending around 2007 when smartphones arrived and research dollars got redirected to cost and power reduction.
We also got stuck with stopgap SIMD measures like SSE/AltiVec instead of a truly scalable multicore/multiprocessor MIMD architecture. Which made it much more difficult to experiment with stuff like genetic algorithms or any other machine learning algorithm that don't map well to vectors. Because a 10 billion transistor GPU that reports thousands of shading units may only have 64 physical cores. Whereas something like a 1 GHz DEC Alpha with 15 million transistors would give us more on the order of 100-1000 cores on the same die, especially if the cache was removed and it used a distributed content-addressable memory for data locality and a near-linear bandwidth increase for workloads like map-reduce.
Anyway, maybe something like MIMD could be built on GPGPU? I just want to get info on my system and see 1024+ threads and 10 TB/sec memory bandwidth on a chip that costs no more than $1000. The fact that this doesn't exist today after all these years, and that people are perfectly happy to keep repurchasing the same desktop computer the same speed as ones from a decade ago, and on top of that go to the ends of the earth to get the simplest shader code working (rather than just coding directly in stuff like Rust/D/C#/Java/C++ and Docker and/or Lisp) just absolutely blows my mind.
In my view, GPGPU is much closer to contemporary Connection Machines, which used Lisp machines for their front-ends. Now the front-end is x86-64 machines running Python instead of Lisp.
Guy Steele wrote the first edition of Common Lisp the Language, the original de facto standard, while working for the makers of Connection Machines.
Similar. So much of llm is about language design and leveraging being able to quickly manipulate semi formal dsls that I think lisp is a brilliant “driver”, so much more so than then current “string templates and regex parsing” approaches.
I wonder, why single Lisp out for a winter? If solving computational problems moves away from writing programs and toward writing GPT prompts, then wouldn't that forecast a winter for every programming language?
I think Lisp is singled out here because it was the original AI language. The original Lisp machine was very expensive, and it was predominantly purchased by institutions for the purpose of AI research.
My source for this is just tidbits I’ve picked up over the years, so I’m not certain it’s factual.
IMHO it's because lisp shines to manipulate symbols whereas the current AI trend is crunching matrices.
When AI was about building grammars, trees, developing expert systems builds rules etc. symbol manipulation was king. Look at PAIP for some examples: https://github.com/norvig/paip-lisp
That stuff works, and requires very low resources by today's standards. You can do symbolic processing in a tiny, low-powered embedded system with no cloud access.
Even today, the accomplishment of SHRDLU remains impressive. And you can actually go into the code to understand why and how it comes up with answers.
Eliza on Emacs (ok, Doctor) it's a good example on this. Pick any Pentium, 486, or RpiB, it will run at crazy speeds. And you can edit it in ELISP to enhance the "personality".
Even if Elisp is not the fastest LISP here at all, it runs fine.
Now if you use SBCL, or cross the parallel Scheme road with JIT'ted Guile3 or use natively compiled Chicken, the performance skyrockets.
I was expecting this to be the recent conversation[1] about Medley Interlisp, presented at Bay Area Lisp almost a month ago. It's been on my list to watch.
I have some interesting IRC logs from Larry Masinter on reviving Interlisp, some regrets about including LOOP into Common Lisp, and so on.