Building a Futuristic Lisp Workstation | Hacker News Reader

Building a Futuristic Lisp Workstation

github.com

52 pointsmgd12 comments

I read the writeup, sounds interesting. My company bought me a Xerox 1108 Lisp Machine in 1982 so I understand the desire for ‘turtles all the way down’ Lisp environment.

All that said, starting with a plain Linux or macOS setup, and build an environment with Emacs, a few Schemes, SBCL or LispWorks, etc. yields a more productive environment that my old Lisp Machine.

I will follow this project, looks really interesting.

Is using emacs in 2024 based on comfort or is there still not a better alternative in VSCode or a separate IDE?

Other than the editors built in to the paid for lisps, nothing comes even close to emacs+sly/slime.

Lsps are am amazing improvement to the average IDE, but is barely of fraction of what common lisps introspection can do.

I also use VSCode and the LispWorks Pro editor, sometimes.

Emacs (besides the lowlevel internals such as the garbage collector, graphics toolkit and virtual machine) is written in Emacs Lisp which means that it's also fully programmable by the user, at runtime, without restarts/loss of state. Moreover, every aspect of Emacs is designed to facilitate runtime modification and live programming. This level of introspection goes beyond anything available today except some Smalltalk environments (which lose on practicality).

VSCode is just another editor with a constrained "API" that limits the modifications one can do. Emacs is clay that one can fully mold to one's own preferences so that it becomes an extension of one's mind.

> This level of introspection goes beyond anything available today except some Smalltalk environments (which lose on practicality).

GNU Emacs has a bunch of user-facing C code which can't be changed live.

Many Lisp systems (and also applications) provide runtime introspection&reflection&modification. See for example Interlisp ( https://interlisp.org ) which was already a full live programming environment with managed source code in the 70s.

It's nice to see Interlisp restored and widely available but it's not Emacs. More a curiosity than something practical and it's looking like it still belongs in the 70s.

There's also Genera (in many ways the best but unfortunately still not widely available), Lispworks (commercial, lacks the features/userbase of Emacs) and a vast number of niche Lisp-based/Smalltalk-based/Forth-based environments that don't come close to the practicality of Emacs.

For all intents and purposes, Emacs is the 'best' freely available and most used Lisp machine we have today, a direct manifestation of Licklider's "Man-Computer Symbiosis".

The recent additions of sqlite3 and native compilation (MPS-based garbage collection is in the works) have significantly expanded the set of problems one can solve. I love Common Lisp but I barely touch it these days, as I tend to reach for Emacs Lisp instead. That's solely down to the evolution and practicality of Emacs.

> More a curiosity than something practical and it's looking like it still belongs in the 70s.

Emacs also belongs to the 70s. The UI basics were from TECO Emacs, mid 70s and many are still there. Stuff like the "Meta" key which no longer exists, or the buffer metaphor. EINE/ZWEI and Multics Emacs were also developed then. Again, the basic stuff is still in GNU Emacs. Cursor handling in GNU Emacs is like it was in the 70s.

> For all intents and purposes, Emacs is the 'best' freely available and most used Lisp machine we have today

I don't see GNU Emacs as a "Lisp Machine", it's a mostly text-ui based development platform & environment written in C+Lisp and its usage is at the same time limited by its oldish user interface. There is a lot of useful software written in it, but the actual broader use of GNU Emacs is limited to a very nerd-like group. I've used GNU Emacs to read/write mail (for example). But that was long ago. There is a limited appeal of the text-oriented UI, which also has a hard time to adapt to devices like phones or tablets.

> practicality of Emacs

The practicality of GNU Emacs is also limited, because its user interface would not reach larger groups of current users.

> but I barely touch it these days, as I tend to reach for Emacs Lisp instead

It's also funny that many people would like to move GNU Emacs Lisp more towards Common Lisp, but they are not allowed to do so... -> see the repeated discussions (since many many years) on the developer mailing list...

> lose on practicality

Compared to Emacs Lisp. How are you evaluating practicality?

They’re using the right pieces to build something like this. And there’s a lot of energy right now around Lisp-ing all of things, largely driven by the Guix people.

You should think of this as the sequel to optimizing your Emacs configuration. There are clear productivity benefits after a steep learning curve that may not be worth it for most people, and the nature of the programs involved means that the final result will always be fiddly and require tinkering.

No one will be able to polish something like this enough to make it usable for you without you putting in a lot of work to make it work for you.

> If in POSIX everything is truly a file, then the logical conclusion is that the ideal POSIX "desktop environment" should be a file editor, and the only editor that can function as such is GNU Emacs.

Is the person thinking of Plan9 rather than POSIX?

Complicating matters further, the Guix project announced support for GNU/Hurd[0], so perhaps everything is a translator (i.e., user-space server)[1]?

[0] https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine...

[1] https://www.gnu.org/software/hurd/hurd/documentation/transla...

Reply on news.ycombinator.com