Why we need Lisp machines

Here's a demonstration of Symbolics Open Genera (TM) 2.0, demonstrated running in a virtual machine. It is noted by the author of the video in the first minute or so that even in emulation, it is much faster than the original machines. - https://www.youtube.com/watch?v=o4-YnLpLgtk

Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible.

The same was true of the Canon Cat, Hypercard, Ted Nelson's Xanadu project, Smalltalk, and a number of other early computing systems.

The main feature common to all of these systems is that they all preserve context. In Genera, Oberon, Canon Cat, Hypercard, and SmallTalk the source was always available. (as far as I know). In Xanadu, the main functionality of the web was present, but it wouldn't allow the broken links (and lost context) that now plague the web.

I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments.

There's nothing stopping an open source project from taking elements of these existing systems and moving forward from that basis. It might be profitable to include ideas such as Coloring of the Source text to label intent, such as in ColorForth.

Also, consider "Literate Programming" - Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code.

You could also add the ability to store graphics and other data along with the source code.

Of course, if you are required to run code you didn't write and don't trust, your operating system must provide means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model.

Sorry it was a bit of a ramble, but this seemed to be a call for ideas, so I ran with it.

PS: In the past, getting your vision of Computing required building a machine, and then getting it manufactured. Now it just requires that you make it work in a VM, Raspberry Pi, or web browser window.

It is MUCH easier to try out and/or create alterative systems now that it has ever been in the past.

I feel like that was one of the core assumptions and point of the article, but it didn’t have any explanation beyond “multiple programming languages.” Feels a bit flat to me.

Today, we have computers that run Lisp orders of magnitude faster than any of those Lisp machines. And we have about 3–4 orders of magnitude more memory with 64-bits of integer and floating point goodness. And Lisp is touted to have remained one of the most powerful programming languages (I think it's true, but don't read into it too much).

Yet, it appears the median and mean Lisp programmer is producing Yet Another (TM) test framework, anaphoric macro library, utility library, syntactic quirk, or half-baked binding library to scratch an itch. Our Lisp programming environments are less than what they were in the 80s because everybody feels the current situation with SLIME and Emacs is good enough.

We don't "need" Lisp machines. We "need" Lisp software. What made a Lisp machines extraordinary wasn't the hardware, it was the software. Nothing today is impeding one from writing such software, except time, energy, interest, willpower, and/or money.

Don't get me wrong, there are some Lisp programmers today developing superlative libraries and applications [1], but the Lisp population is thin on them. I'd guess that the number of publicly known, interesting (by some metric), and maintained applications or libraries that have sprung up in the past decade probably fits on one side of a 3"x5" index card. [2]

Though I won't accuse the article's author of such, sometimes, I find, in a strange way, that pining for the Lisp machines of yore is actually a sort of mental gymnastic to absolve one for not having written anything interesting in Lisp, and to excuse one from ever being able to do so.

[1] Just to cherry-pick a recent example, Kandria is a neat platformer developed entirely in Common Lisp by an indie game studio, with a demo shipping on Steam: https://store.steampowered.com/app/1261430/Kandria/

[2] This doesn't mean there aren't enough foundational libraries, or "batteries", in Lisp. Though imperfect, this is by and large not an issue in 2022.

In fact I conjecture that this is the reason Unix is more popular than Lisp -- because Lisps don't interoperate well. They haven't built up a big ecosystem of reusable code.

Whereas Python, JavaScript, R, C, C++, and Rust programmers can reuse each others' code via Unix-style coarse-grained composition. (Not just pipes -- think about a web server running behind nginx, or git reusing SSH and HTTP as transports.)

You can also use link time composition. It takes some work but it's better than rewriting your Common Lisp code from scratch in Clojure.

-----

Honest question: how do you communicate between two Lisp processes on two different machines? I know Clojure has EDN (which is sort of like JSON : JavaScript), but I haven't heard of the solutions for other Lisps.

I wrote about this problem here: A Sketch of the Biggest Idea in Software Architecture http://www.oilshell.org/blog/2022/03/backlog-arch.html

> The lowest common denominator between a Common Lisp, Clojure, and Racket program is a Bourne shell script (and eventually an Oil script).

I'll definitely update it if there's something I'm missing.

I would say the design of Unix is "rotting", but the answer is to IMPROVE Unix. Not dream of clean slate designs that will never be deployed. Plus this post doesn't actually propose anything. If you actually start trying to build your Lisp machine, I believe you will run into dozens of reasons why it's not a good idea.