> What would the LISP machines have been like? It still kills me to think that an OS crash on one of those took you into the Lisp debugger.
Sometimes I think a lot of people do use LISP machines. It's just called emacs.
I joked on here once that I think the end game for GNU/HURD was ultimately to become a LISP machine via emacs, and if you look at some dev setups, that's not too far from what macOS and Linux are for them today: a place to run emacs and a web browser.
"GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer filenames, file version numbers, a crashproof file system, filename completion perhaps, terminal-independent display support, and eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages. We will have network software based on MIT's chaosnet protocol, far superior to UUCP. We may also have something compatible with UUCP."
Not many people today would think of their "GNU/Linux" system as a Lisp machine anymore than anybody thinks of their Chromebook as a JavaScript machine, nor is it really comparable to the Lisp Machines of the past.
I fully agree that GNU/Linux is nothing like a Lisp Machine, but that is because things didn't go according to the original plan (otherwise we would be talking about GNU/Trix).
One interesting thing about the original plan is that Unix was essentially text only back then. Part of the idea of making it more Lisp Machine-like was to have a GUI, so when Unix got that (with X11 eventually winning) this part of the plan became less urgent.
I suppose an Emacs OS would be sort of a GUI but not quite?
The MIT derived Lisp Machines had all an Emacs called Zmacs.
But that was just one application among dozens others. Applications usually were not based on Zmacs, with only a few exceptions: on a Symbolics: Zmail and the Concordia documentation editor application frame. Other tools were not Zmacs based: Listener/REPL, the debugger, the directory editor, the font editor, the PEEK tool to view system details, the document examiner, the tape tool, ...
The problem for me with Emacs is that (while I use it everyday for just about all editing, and recently org-mode) it's so damn brittle and hard to configure. It's like editing autoexec.bat on DOS and reboot to try your settings. Still, it's the best I've found.
I hope you don't reboot Emacs on every config change?
M-x eval-region, M-x eval-last-sexp and M-x eval-buffer are your friends. Emacs is, as suits a Lisp system, strongly runtime-modifiable. It even has its own REPL - M-x ielm.
Then there was the access of the complete OS stack and other running applications, and everything was compiled to native code, there wasn't any VM running.
Try do do a (disassemble func) on Emacs for seeing actual 80x86/ARM,....
Sometimes I think a lot of people do use LISP machines. It's just called emacs.
I joked on here once that I think the end game for GNU/HURD was ultimately to become a LISP machine via emacs, and if you look at some dev setups, that's not too far from what macOS and Linux are for them today: a place to run emacs and a web browser.