Comment by lispm | Hacker News Reader

Comment by lispm | Hacker News Reader

Parent Full thread

If you have a Raspberry Pi, you have already all the hardware to run Lisp. There is very little reason to develop special hardware. Lisp runs nicely on an ARM processor.

Actually some the first ARM processors were supposed to run a Lisp operating system. When Apple did the research&development for the Apple Newton, they originally attempted to run a Lisp-like system on mobile systems like PDAs and tablets. This Lisp dialect was derived mostly from Scheme and Common Lisp - the language was eventually called Dylan. Apple had ARM systems in their lab which ran a Dylan OS. When they at one point chose the ARM processor, Apple invested in ARM and they used a chip which was able to support a garbage collected language. Unfortunately these Lisp operating systems by Apple did not reach the market and Apple instead sold the Apple Newton with an OS kernel written in C++ and the software on top written and scripted in NewtonScript - a language with many aspects from Lisp - incl. garbage collection.

Could you explain what you mean by a "Lisp operating system"? I understand the idea of Lisp as a language, but what does Lisp as an OS mean?

Historically it's an operating system written in Lisp, typically running as a Lisp runtime+image on the metal. Itself providing memory management, interrupt handling, process scheduling, network I/O, graphics, keyboard, mouse, windows, applications ... and everything else a typical OS provides.

For a recent attempt see: https://github.com/froggey/Mezzano

Is there any advantage to that over a generic OS? I have not, in general, cared what language my OS was written in.

First off, note that Lisp OSes were made before modern cybersecurity was a concept.

Since everything was Lisp all the way down, and Lisp is a very dynamic language, all calls that comprise the OS are available as plain function calls visible to the interactive REPL, introspection, and modification. They were very developer-oriented and had lots of ways to have live displays of objects, to reuse or interact with them, and very deep debugger and documentation integration, since all code was at the same "level".

Since it's a high level language that does not expose low level memory (although certainly there are obscure implementation-specific Lisp operations for doing so used deep in the guts), corruption of memory at a low crashy level isn't generally a thing. Protections between applications/processes aren't as necessary and it can all remain plain running threads & functions interacting with each other & the OS.

So there isn't really a distinction between the OS and the API? (That is, the Linux kernel, say, is a monolithic binary. Then we have the OS utilities that make up the GNU/Linux OS. And then we have the C - or whatever - standard library API. If I understand you correctly, those distinctions would not exist in a Lisp OS.)

Correct. It's not a process-oriented environment, with crash protection facilities keeping everything at arm's length.

There are namespacing facilities (though I'm not sure how far back in history they go) to discriminate your code's reach, as well as to import the public API from others' code, or in a different manner to bore into their private affairs generally for admin/debugging/tracing/modification. "Global" variables have thread-local, dynamically scoped bindings which are super useful for configuration, redirection, or setting other side-band broad context when calling into shared code.

Also it should be noted that these types of machines (at least from the Symbolics point of view) tended to be single-user workstations, though were still networked to allow remote (and simultaneous) access to its running world, with varying levels of per-connection context.

One of the biggest downsides of ye olde Lisp machines was garbage collection times. Some had facilities to define dedicated heap regions, but generally the GC had to walk the entire workstation heap across all "applications" in 1980s hardware, which wasn't great. But at least as a programmer, you could freely code and only worry about minimizing GC pressure when it became an issue, instead of starting from a required malloc/free perspective and constantly worry about leaks.

> Some had facilities to define dedicated heap regions, but generally the GC had to walk the entire workstation heap across all "applications" in 1980s hardware, which wasn't great.

a stop-the-world global GC was generally tried to be avoided. mid 80s Symbolics Genera had regions for data types (areas), areas for manual memory management, a generational GC, incremental GC (the GC does some work while the programs are running) and an ephemeral GC efficiently tracking memory pages in RAM. For normal use it then looked like global stop-the-world GCs were only used in special situations like saving a GCed image or when running out of free memory. But one often preferred to add more virtual memory then, save the work and reboot. For that one could add paging space when Lisp crashed with an out-of-memory error and continue from there.

Emacs.

(Only half joking)

Well, there is a port of glibc to UEFI, so one could very easily "boot into Emacs". Strangely I've not seen anyone do this.

Here is boot into emacs implemented by making emacs the Linux init program, "Emacs standing alone on a Linux Kernel"

https://www.informatimago.com/linux/emacs-on-user-mode-linux...

This is different to what I was talking about -- your link is about running Emacs as pid1 on Linux (cool, but not particularly innovative -- if you run Emacs in a Docker container that is effectively what you're doing). I was talking about booting from UEFI into Emacs, without the Linux kernel at all. Given that there is a glibc port for UEFI that uses just BootServices it would be very possible to do this.

Ah yes, I see. Something like this has been done with Python. It was surprisingly difficult, I thought.

Python without an operating system https://news.ycombinator.com/item?id=9453677

Porting Python to run without an OS https://www.youtube.com/watch?v=bYQ_lq5dcvM

not really. GNU Emacs is not even good at multi-tasking.

Actual Lisp operating systems also don't look like an Emacs running on hardware. The MIT Lisp operating system had Zmacs, but it was one application among others and while Zmacs had modes (incl a Dired), the typical Lisp OS application was not an Zmacs mode. None of these were based on Zmacs: the Listener (the REPL), the process overview, the font editor, the inspector, the terminal, the chat program, the documentation reader, ... On a Symbolics there were basically two major other programs reusing parts of Zmacs in their UI: the mail client and the documentation editor.

Thus when people think that a Lisp OS looks, feels or works like an Emacs on the metal or that GNU Emacs looks like the typical Lisp operating systems from the 80s (from MIT, Symbolics, LMI, TI or Xerox), then this is actually not the case.

See this for an example how an 3d animator used a Symbolics Lisp Machine and parts of the graphics suite for it: https://youtu.be/8RSQ6gATnQU

Reply on news.ycombinator.com