The early LISP crowd just didn't get the concept of making a product. The idea that eventually you generate an executable and leave the development environment behind was totally alien. I used Berkeley's Franz LISP in my years at the aerospace company. That was a compiler which generated .o files. So they were close to being able to do this.
But you didn't link the .o files; you had to load them into the development environment to run them. Compiling was just an optimization. I asked the Franz LISP devs why they didn't provide a runtime you could just link in, yielding a releaseable executable program without all the baggage for breaking and debugging. This was a totally alien concept to them.
INTERLISP and Symbolics were even worse - you were always in the development environment and couldn't get anything out except a saved state dump.
Eventually the LISP crowd got it and started generating executables, but it was too late by then.
> ... Symbolics were even worse - you were always in the development environment and couldn't get anything out except a saved state dump
Symbolics had a delivery Lisp on DOS/Windows called CLOE.
On a Lisp Machine one also was not always in the full development environment. But Lisp was the operating system and thus Lisp plus some dev tools was always there. But when one wanted to use the development environment to its full capability one would need to load more stuff and create worlds with more debug information.
The delivery of Lisp applications wasn't a thing until after the mid 80s. Before that there were not that many Lisp applications and not too much machines to install it on. This changed with UNIX workstations, 386/486 PCs, Macs with 68030/40. Even in the early 90s there were questions how to deliver Lisp software in static form to end users. The question was often answered with "rewrite it in C++". Sometimes: prototype it in Lisp and then rewrite it in C++. Sometimes: migrate to C++. Sometimes: use a Lisp compiler generating C code.
For some discussion of delivery problems in Lisp see the German Apply project from 1992:
Don't forget dedicated "delivery" 36xx series machines from Symbolics, which were lower priced specifically because they weren't supposed to be used with the development environment.
Minima was, AFAIK, special real-time variant of the Genera system, with noticeable differences - it also ran a different firmware at least on Ivory (differences in FEP<->OS interface from what I figured spelunking in code).
Minima was also used for some debug tooling for building the machines themselves, iirc.
I used Berkeley's Franz LISP ...That was a compiler which generated .o files.
... But you didn't link the .o files; you had to load them into the development environment to run them. Compiling was just an optimization.
That sounds the same as Python and Java work now. For python, you have .py source code files or .pyc or .pyo compiled files, but you still have to load
them into the Python interpreter.
I asked the Franz LISP devs why they didn't provide a runtime you could just link in, yielding a releaseable executable program without all the baggage for breaking and debugging.
Even now, you typically need to have Python or Java installed on your computer to run Python or Java programs. There are ways to generate standalone Python executables but it's not the usual way of working.
I'm not asking for it as such, but the claim that Lisps now produce "executables" is sometimes still not quite what people have in mind. It's still a whole bundled Lisp runtime, not unlike using PyInstaller to bundle an entire Python runtime in an executable.
Most languages need some runtime. In the case of Lisp it starts with the basic memory management, since Lisp by default needs a garbage collector. This memory management is usually not provided by the operating system. It needs a basic interface to some OS stuff, threads, etc.
A Lisp executable then can be one file which includes a runtime and the (compiled) Lisp code. One could also have these as two separate files.
The there are two basic ways to provide the Lisp code: it's either just compiled code or a memory image of containing the code. SBCL uses the memory image approach. ECL (Embeddable Common Lisp) uses the 'compiled code' approach. ECL compiles to C and then adds the compiled C code to its runtime.
INTERLISP and Symbolics were even worse - you were always in the development environment and couldn't get anything out except a saved state dump.
Eventually the LISP crowd got it and started generating executables, but it was too late by then.