Lisp machines, and what specialised hardware taught everyone else

late 1970s and 1980sWhat the hardware did

These were machines designed around one language rather than adapted to it. Words carried type tags in hardware, so checking a type cost nothing. The instruction set was implemented in microcode written for the language's operations. The memory system assisted garbage collection directly rather than leaving it entirely to software.

The result was that a language considered impractically slow on ordinary machines ran well, and the environments built on them were years ahead of anything else available.

1980sWhat they were competing against

General-purpose workstations, built from commodity parts, sold in far larger numbers, and improving on a curve driven by an entire industry rather than by one specialist company.

Being ahead at any single moment was not the relevant comparison. The relevant comparison was between the rate at which a specialist improves its own design and the rate at which everyone else improves the general one.

late 1980sThe crossing

Compilers for stock hardware got better at exactly the things the special hardware existed to provide, and the stock hardware got faster at a pace no single vendor could match.

Once the general machine ran the language acceptably at a fraction of the price, the argument was over, and it was over quickly rather than gradually, because the customers were mostly buying a language environment rather than a machine.

late 1980sThe other blow

The market for these machines was concentrated in one field of research, and that field lost most of its funding in a short period. A specialised product with a single large customer base is exposed to that customer base in a way a general one is not.

Both causes are usually offered as the whole explanation by people who prefer one of them. Both operated, and either alone would probably have been survivable.

present dayWhat they were right about

Type tags in hardware, memory that assists in checking rather than merely storing, and treating safety as an architectural feature rather than a software discipline.

All three have returned. Processors now ship with memory tagging designed to catch exactly the misuse that manual memory management produces, and research architectures carry capabilities in hardware with the same intent. The idea was not wrong; it was expensive, specialised, and forty years early.

What they were also right about, and nobody mentions

The environments. Symbolic debugging into running systems, the ability to inspect and change anything, and documentation integrated with the code were ordinary features there while everyone else was editing files and reading printed manuals.

Much of that has arrived since. None of it arrived from them, which is the recurring melancholy of this part.

The general lesson

Specialised hardware loses to general-purpose hardware whenever the general curve is steeper, regardless of how much better the specialisation is at the moment of comparison.

That has held repeatedly since, and the exceptions are instructive: specialisation survives where the workload is enormous, stable, and worth its own silicon. Where it is any of those things less, the general machine catches up before the specialist can amortise the design.

What the tags actually bought

Concretely: a machine word carried a few bits saying what kind of value it held, and the processor checked them as part of the operation rather than as extra instructions.

A dynamically typed language on ordinary hardware pays for that check in software on every arithmetic operation, or pays a compiler team to prove it unnecessary. Doing it in the instruction removes both costs, which is why the same language could be fast there and slow everywhere else.

1980sThe company as a warning

The vendors were vertically integrated: they made the processor, the operating system, the language implementation and the applications. That produced coherence no assembled stack could match, and it meant every improvement anywhere had to be funded by one company's revenue.

When the revenue fell, everything stopped at once. A stack assembled from independent parts degrades one part at a time; an integrated one has no partial failure mode.

2010s onwardsWhere the specialisation argument reversed

The general lesson has one large modern exception, and it is worth stating because it looks like a contradiction and is not.

Dedicated hardware for one narrow kind of arithmetic now dominates a large field, because the workload is enormous, extremely stable in shape, and worth designing silicon for. That is exactly the condition the earlier machines lacked: their workload was a whole programming language, which is neither narrow nor stable, and their market was a research field rather than an industry.

present dayWhat survives to be used

Emulators and preserved images exist, and the environments can be run. That is worth knowing because arguments about them are usually conducted from memory, and the systems are available to be examined.

What cannot be reconstructed is the experience of that environment being the fastest thing available rather than a historical curiosity running inside something faster.

What we cannot verify

The architectures are documented and the machines are described in manuals that survive. The relative weight of the two causes of their disappearance is argued about by participants with strong views, and we take no position. Performance comparisons from the period are not reproducible and should not be quoted as though they were measurements.