Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

> ... 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:

https://www.researchgate.net/publication/229022605_APPLY_A_m...

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.

For those there was also a system called "Firewall", which shields the end user from the underlying Lisp in some way.

Then there were also delivery systems on the Ivory. There was even a stripped down Lisp operating system called Minima for those, IIRC.

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.

A customer wanted to have multiple nodes running Minima for a network switch, IIRC.

Having Genera/Ivory boards in a Mac was also seen as a delivery vehicle. For example:

http://www.bitsavers.org/pdf/symbolics/software/genera_8/Mac...

"MacIvory Delivery is not suitable for application development or debugging.... MacIvory Delivery is tailored for delivery environments"

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.

> That sounds the same as Python and Java work now.

Not really, the .o files were fully compiled, they just needed to call C functions in the Franz Lisp runtime.

Franz Lisp could generate executables from the beginning, the debugging features didn't add much to the size.

You could export something runnable from the dev environment, but it was, I think, a copy of the dev environment.

Was it an executable that you could release to clients or not?

Aren't SBCL and Chez executables basically just dumps of an environment?

You need all that with SBCL, because you can call all that from a running Lisp program.

Perhaps you are asking for that to be available as a library? The size isn't very large so it's not big a deal.

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.

The concept of (development) environment as separate from the program is alien to Lisp.

Reply on news.ycombinator.com