Part of what killed it, besides not having the economy of scale in microprocessors, is that optimizing compilers got good at turning loops over integers into fast code for regular CPUs, and these are pretty important for overall system performance. So no matter how much faster a custom CPU could run eval, it wasn't going to be competitive at integer loops.
But otherwise I think you're spot on, and it's a common arc in this industry: company comes up with a true innovation solving a problem better than the competitors, Moores law does it's thing, suddenly the COTS products are competitive through brute force if nothing else at a lower price point, and company either has to innovate again or embrace a COTS platform. Jim Gettys wrote a neat paper about how this effected high-end video cards back in the early X11 days (admittedly, no longer directly applicable since GPUs are the COTS solution now, but the principle stands).
Lisp machines only made any sense in that very brief window when DRAM was faster than the CPUs that used it. Partly because of process technology, partly because of lack of understanding of CPU design principles. With x86, you could choose to ignore the parts of the design that made it slow, and just build on the basics to bring the design forward. With a lisp machine, that would have never worked.
It wouldn't have been long until you would have been able to buy machines that would have been more than 10x faster on real workloads, and probably cheaper too.
Unlikely. For this to happen, the developers would have had to target the mass market (i.e. working hard to make the processor and a computer based on it rather cheaply available for the masses). This is clearly not what SCHEME-78 was developed for.
People were already buying computers that cost more than cars and they ran like molasses.
You have to deliver what customers want on their terms, not program on your own terms.
I'd argue users wanted off the shelf software, not bespoke solutions, which is why they were cool with slow machines that ran 123, dBase and Wordperfect.
Anything to do with graphics and games, yes only Assembly would do the trick.
DBase was written in assembly first, word perfect was written in assembly first.
Yet, the folks down at the bank, insurance companies, and video rentals, were using DBase applications written in xBase, compiled via Clipper, not Assembly.
My first computer was a Timex 2068, I kind of know what was being written with what.
They were never going to catch on and it was never going to work because people didn't want them. Programmers might have wanted to program in lisp, but users didn't want to buy software made in lisp.
For some reason you're bringing up that someone may have written some scripts in an interpreted language which if anything reinforces that lisp machines weren't necessary.
Followed by
> I don't know what you're trying to say here, all those programs would have run terribly if they were written in lisp or scheme.
While dBase was written in Assembly, the interpreter, Clipper, the compiler was written in C, and dBase software written in xBase programming language, a programming language that by Clipper 5 days was just like Lisp or Scheme in capabilities, garbage collected, able to do functional programming, and OOP, in 640 KB, running on 20 MHz CPUs.
They couldn't do what people wanted. People didn't want their software written in lisp, they didn't want expensive hardware and slow software. Who cares if that software had interpreters in it?
I was there, and wrote my share of Clipper and DBase III code, among many other things.