The Lisp Machine Myth: Why Nostalgia Hinders Modern Lisp Development

In a pointed critique published on his personal site, long-time Lisp practitioner Thomas F. Ellis (tfeb) calls for an end to the 'Lisp machine romantics'—those who mythologize the specialized hardware of 1980s Lisp machines like the Symbolics 3600 as the pinnacle of development environments. Symbolics went bankrupt in 1993, marking the end of an era that spanned roughly five years of commercial viability from 1983, but Ellis argues the machines were doomed earlier by the rise of RISC architectures and cost-effective stock hardware.

"It is time, and long past time, to let them go."

Ellis, who used Lisp machines from both major families (Symbolics and LMI) from 1989 into the late 1990s, draws on firsthand experience to debunk common claims. He traces the decline to systems like the Sun 3/260 'AI' configuration, which by 1987 outperformed Symbolics machines on Gabriel benchmarks using Kyoto Common Lisp—a non-optimized implementation.

Debunking the Myths

Myth 1: The Development Environment Was Unmatched

Lisp machine environments were 'seriously cool' for their era, Ellis concedes, excelling at hiding slow restarts and large image sizes in an age of limited memory. But these advantages stemmed from software ingenuity, not hardware:

"[T]here is no reason at all why a development environment that cool could not be built on stock hardware... LispWorks [today] is at least as comfortable and productive as they were."

Modern tools like LispWorks match or exceed 1980s environments, despite not being open source—just like the originals.

Myth 2: Superior Speed and User-Microcodability

Performance claims don't hold up. Early RISC machines beat Lisp machines on benchmarks, and microcodability was a CISC-era workaround for complex instructions (e.g., type-dispatching add) that compilers could handle on simpler hardware. Users rarely wrote microcode; it was a vendor tool for constrained resources.

Ellis notes RISC architects anticipated Moore's Law, betting on exponentially cheaper memory to offset larger code sizes—a wager that paid off.

Myth 3: 'Lisp All the Way Down'

The deepest appeal—full-system introspection and modification—remains compelling but feasible today without custom silicon. Low-level hacks like streaming sound from disk were possible due to Lisp's uniformity, but modern equivalents demand security isolation:

"[A] machine that was Lisp all the way down today would need to ensure that things like [a web browser modifying device drivers] couldn’t happen."

Ellis challenges romantics: hardware isn't the barrier. Build it now on GPUs or commodity clusters.

Myth 4: Compilers Need Special Hardware

Contemporary Common Lisp compilers like SBCL rival LLVM in floating-point performance, with differences under 1.2x on Arm64 (e.g., Apple M1). Compilation is fast enough for EVAL-when-needed, and techniques from Julia's JIT ecosystem are ripe for reuse.

"The tradeoff between a fast Lisp compiler and a really good Lisp compiler is imaginary, at this point."

Gear Acquisition Syndrome in Programming

Ellis likens Lisp machine nostalgia to 'GAS' (Gear Acquisition Syndrome) in photography and music: an excuse to chase mythical hardware rather than honing craft. Like HPC veterans mourning Crays, Lisp developers fixate on 40-year-old tech while ignoring cheap GPU farms or stock RISC-V.

The post, dated November 18, 2025, urges action over mourning: modern Lisp excels where it should—dynamic, interactive systems—not reinventing OS kernels or SSL stacks.

In an era of maturing JITs and LLVM backends, Lisp's potential lies in software innovation, not hardware revival. Ellis's manifesto is a call to 'shut up and code,' freeing developers from self-imposed barriers of nostalgia.