Conversation with Larry Masinter about standardizing Common Lisp
irclog.tymoon.eu
irclog.tymoon.eu
I have some interesting IRC logs from Larry Masinter on reviving Interlisp, some regrets about including LOOP into Common Lisp, and so on.
> 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.
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
So how did they resolve them?
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.
https://en.wikipedia.org/wiki/Multiple_instruction,_multiple...
We did have the Xeon Phi until recently: https://en.wikipedia.org/wiki/Xeon_Phi
It was a lot of simple (derived from the original Pentium) x86 cores on the same die, as you want.
Would be nice if scaled up, I think. Give it a few years time :-)
Guy Steele wrote the first edition of Common Lisp the Language, the original de facto standard, while working for the makers of Connection Machines.
My source for this is just tidbits I’ve picked up over the years, so I’m not certain it’s factual.
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
This paradigm has changed.
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.
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.