To me, it was never about the hardware. It was not even about LISP. It is about "clean design" and what a great computing environment was capable of, and still would be, had its potential not been shredded by the advent of cheap addicting hardware combined with an "operating system" so "simple and elegant" that even today, a program simply segfaults leaving you with nothing (instead of showing at least an inspectable…
I don’t want an Open Genera machine in a portable case with a battery, though. I want Apple’s software to match the quality of their hardware.
Fun fact: NeXT's Interface Builder was originally built in Lisp. So Apple software was really good at one point, in part because someone wanted to bring the Lisp machine to the NeXT environment.
Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…
Xerox/Venue tried porting Interlisp (the Lisp machine environment developed at Xerox PARC) to both Unix workstations and commodity PC hardware, but it doesn't seem like that was a commercial success. Venue remained a tiny company providing support to existing Interlisp customers until its head developer died in the late 2000s and they wrapped up operations. The Unix/PC ports seem to have mostly been used as a way to…
The environment lasted a long time as the basis for other Xerox products, such as their office automation system and as a front end for their printing systems. However, it wasn’t so much ported as the virtual machine was. (Just like Symbolics did with OpenGenera on Alpha.)
What I’m suggesting is that they could have done a full port to the hardware; OpenGenera is still an Ivory CPU emulator. In 1986-7 you could get an AT-compatible 80386 system running at 16-25MHz that supported 8-32MB of RAM for 10-20% the price of a Symbolics workstation, and while it might not run Lisp quite as fast as a 3600 series system, it would still be fast enough for both deployment and development—and the next generation would run Lisp at comparable performance.
Symbolics’ big fumble was thinking their CPU was their special sauce for way too long. They showed signs that some people there understood that their development environment was it, but it obviously never fully got through to decision-makers: They had CLOE, a 386 PC deployment story in partnership with Gold Hill, but they’d have been far better served by acquiring Gold Hill and porting Genera to the 386 PC architectu…
To be fair to Symbolics: a lot of companies back then thought their CPU was the secret sauce. Some still do...
I think Apple knows that it's the whole widget (including software and hardware) that matters.
I worked on Franz Lisp at UCB. A couple of points: The ".obj" file was a binary file that contain machine instructions and data. It was "fast loaded" and the file format was called "fasl" and it worked well. The issue of building an application wasn't an issue because we had "dumplisp" which took the image in memory and wrote it to disk. The resulting image could be executed to create a new instance of the program, a…
I was doing this in 1980-1983. Here's some code.[1] It's been partly converted to Common LISP, but I was unable to get some of the macros to work. This is the original Oppen-Nelson simplifier, the first SAT solver. It was modified by them under contract for the Pascal-F Verifier, a very early program verifier. We kept all the code under SCCS and built with make, because the LISP part was only part of the whole system…
The Nelson-Oppen simplifier is a great piece of work, but it is not the first SAT solver. Boyer and Moore published their formally verified SAT solver in their 1979 A Computational Logic, the first book on the Boyer-Moore Theorem Prover, though it was first implemented I believe in 1973. This algorithm, based on IF-normalization and lifting, was also a core part of the original Boyer-Moore prover. One interesting note is that it actually was almost an earlier discovery of BDDs - they have the core BDD data structure and normalization algorithm but were just missing memoization and the fact that orderings on variables induce canonicity for checking boolean equivalence! But in any case, Boyer-Moore had a (formally verified, even!) implemented and used SAT solver long before Nelson and Oppen.
Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…
TCL has good solutions for this, but its not made it a success. Where I see Python used is in places where you do not need it packaged as executables: 1. Linux - where the package manager solves the problem. I use multiple GUI apps written in python 2. On servers - e.g. Django web apps, where the the environment is set up per application 3. Code written for specific environments - even for specific hardware 4. One of…
It seems the other way to me, maintaining environment consistency is such a pain that even a 5 line Python script ends up getting packaged in its own Docker container.
A lot of this could be said about specialized machines in general. I remember visiting the local university last century where a guy was demonstrating a US-made Word Processor machine they had bought, and around the same time a local company was developing something similar. And they looked very cool indeed. But in both cases I thought.. "eh, won't that be total overkill now when we can see standard word processing s…
Ivan Sutherland observed the same cycle in graphics processors and called it "the great wheel of karma".
An interesting article. And the HPC footnote puts some perspective on today’s fad: “AI”. The specialized hardware of today will be close-to-commodity tomorrow and today’s data monsters will be nothing but energy-wasting curiosities tomorrow. Maybe some will be preserved in a museum.
Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perh…
Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infan…
I don't generally see this kind of issue with UV, at least not with the ultra popular libraries.
With the exception of Gstreamer. I use some awful hacks to break out of virtual environments and use the system Gstreamer, because it's not on PyPi....
As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed with the LISP machine. The performance wasn't all that great. Initially garbage collection took 45 minutes, as it tried to garbage-collect paged-out code. Eventually that was fixed. The hardware was not very good. Too much wire wrap and slow, arrogant maintenanc…
> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks
python comes to mind here. I have almost never had a deployment go smoothly.