* relatively complex code
* grown system with lots of legacy code
* depended on certain hardware or its emulation -> not portable to other architectures
* almost no security story
* optimized for single-user GUI workstation use, other types (headless servers, ...) not so
well supported
* not multi-user capable
* weak support for terminals
* would have needed more bug fixing
* more difficult to use with standard keyboards
Was the lisp machine OS fundamentally non-portable to other hardware? It's my impression that it could have been, with similar amount of effort to making the first port of any OS.
Unix is intended to be portable, but creating and maintaining a port (including compilers and drivers) is a large effort, and somehow a community never materialized around supporting Lisp Machine on PCs, the way Unix on PCs did.
The MIT Lisp Machine had been developed further and ported to a bunch of CPUs. LMI and Symbolics started with the original CPU. Symbolics then developed a 36bit machine and later a 40bit machine. TI developed 32bit machines. LMI and Symbolics were working on a new generation, which did not reach the market.
All these released CPUs were basically stack-based architectures with a bunch of Lisp support and even some esoteric stuff. Early CPUs had writeable microcode, so that special instruction sets could be developed and improved.
The main compiler/runtime was never (AFAIK) ported to support conventional CPUs of CISC or RISC types with mostly fixed instruction sets. Symbolics seems to have been working on a portable Common Lisp (for Unix etc) for a short period of time, but I have not heard of a portable OS on 'conventional' CISC/RISC hardware. Symbolics developed an embedded version of their OS, but still for Symbolics hardware.
I can't remember that that any of the competitors were developing a Lisp OS on top of something like SUN/IBM/Apollo/SGI/DEC/... hardware. Xerox had their Lisp OS ported to SUNs as emulation and you would run it on top of some SUN OS / Solaris. Symbolics ported theirs as emulation on top of DEC ALPHA / Unix.
For companies like SUN, DEC, IBM, SGI, etc. it was possible to license some core OS and develop from there. But there was no portable core Lisp OS to license. One could license the MIT Lisp OS, but the code you got from them was for a special Lisp hardware.
Symbolics and TI were able to use some standard chips for some interface functions in some of their systems. It's not just the CPU, which needs to be supported, but also the hardware for serial interfaces, ethernet, graphics, disks, wireless, ...
What I find on getting them running without LISP hardware is somewhere between tough and "wow, I feel for that person." Maybe things have improved. There just seems to be a huge mismatch between many aspects of LISP machines and modern machines that means it's probably easier to do a clean-slate LISP machine that builds on modern primitives & interfaces better.
Stallman was a noted Lisp hacker, yet chose to develop a C compiler and clone the Unix user space for his free software project. Stallman killed Lisp; yeah, that's it. ;)
I mention that because there is Unix on PC's that isn't free, and heavily indebted to GNU.
Proprietary Unix on PC hardware is an insignificant blip in computing history.
A writeup on Xenix indicated it had huge impact in getting UNIX into more universities and created tons of market demand for PC UNIX. If that's true, then it's not so much an insignificant blip as a huge part of the reason for FOSS UNIX's success if they benefited from contributors from those universities or demand they generated.
Then it becomes a relic of history with lasting influence from there. Unless you count the Linux distro's people paid for. Two of those are still leading with a more, usable one mostly happening due to paid, support model. Seems like proprietary UNIX on PC's just shed its skin and took a new form that dominates UNIX on PC's to this day albeit with more benefit to users. ;)
I was thinking in terms of the ability to do the OS with LISP with some of its advantages in development, maintenance, or customization per user. Except done on modern systems in ways users might actually use.
I still thank you for the response since I like learning about LISP machines and reasons for failure. This is a nice list of stuff to avoid in the next one where applicable.
