Thesis: the ideas behind Lisp are having a renaissance, and the closer machines get to superintelligence (SI), the more those ideas matter. And not necessarily Lisp itself: the language SI ends up thinking in may well be written by machines, for themselves, and it will turn out to be Lisp-like.

A Language Born for AI

Lisp and artificial intelligence share a birth certificate. John McCarthy coined the term “artificial intelligence” for the Dartmouth workshop of 1956, and two years later he started Lisp at MIT, as a language for machines that reason in symbols. Its heart, eval, fits on half a page of Lisp itself; Alan Kay called that page “the Maxwell’s equations of software.” Garbage collection, the REPL, the conditional expression, dynamic typing: all Lisp firsts, all mainstream today.

For thirty years Lisp was the language of AI. Then symbolic AI went into its winter and took the Lisp machines of the eighties down with it. What won in the end was neural networks, which learn from data instead of being handed rules. Rich Sutton called it the bitter lesson: general methods that ride on computation beat hand-built knowledge, every time.

The twist is that neural networks, having beaten symbolic AI, are now rebuilding Lisp’s ideas from the inside.

What Lisp Offers — All at Once

Four features, and the point is that they come as a package, not as libraries you have to stitch together:

  1. Code is data. A Lisp program is written as S-expressions, which are trees. The line between “writing code” and “running code” is almost erased: a program can build code on the fly and run it.

  2. Metaprogramming. Since code is data, a program can take its own structure, rewrite it, and run an updated version of itself. Macros are programs that write programs.

  3. The condition system. In most languages an error flies up the stack and is either caught or crashes the program. In Common Lisp the stack isn’t unwound right away: the code that failed offers ways out — restarts — a handler higher up picks one, and the work goes on from the point of failure without losing context.

  4. The REPL. Read, eval, print, loop: a live system you talk to, inspect and change while it runs, without ever starting over.

What Today’s Models Rebuilt

A couple of years ago the picture was this. Neural networks are “System One” in Kahneman’s terms: fast, intuitive, instant. Hence the weaknesses: confident blunders, poor at long logic, arithmetic, multi-step planning. “System Two” — slow, step-by-step reasoning with self-checking — had to be bolted on with prompts.

That picture is out of date. Since late 2024 models have been trained to reason with reinforcement learning: they think at length before answering, check themselves, back out of dead ends. Nobody wrote “wait, that’s wrong” into them — it showed up on its own in training (DeepSeek’s R1 paper calls it the “aha moment”). And they no longer just talk: agents write code, run it, read the error, fix it and run it again, for hours. Each of these tricks maps onto a Lisp capability:

  • Thought as a program. A chain of thought is a program the model writes for itself and immediately runs, and agents that act by writing code tend to beat agents that fill in JSON forms. The line between code and execution is erased — Lisp’s founding move.

  • Search with backtracking. Try a branch, hit a dead end, back up, take another; sample many lines of thought and let a verifier keep the good ones. That’s tree traversal — exactly what Lisp was built for, since S-expressions are trees.

  • Failure as a fork. An agent whose command fails doesn’t crash: the error comes back as an observation, and the model chooses what to do — retry, take another route, ask the human. That’s handlers and restarts, rebuilt out of chat turns. A human approving an agent’s next step is the Lisp debugger asking which restart to take.

  • The loop itself. Read the state, eval a step, print the result, loop. A coding agent is a REPL with a model at the keyboard.

Philip Greenspun’s tenth rule says: “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” Today’s agent stacks — prompts, JSON tool schemas, Python harnesses, sandboxes, retry loops — are that rule at datacenter scale. The resemblance is conceptual: it’s about form and ideas, not a call to rewrite the stack in Lisp. But the form keeps coming back, because the problems are the same.

Why SI Makes It Sharper

The big labs now name superintelligence as the goal, and the mechanism everyone points to on the way there is recursive self-improvement: a system that improves the very thing that improves it.

Its first rough forms already work. DeepMind’s AlphaEvolve (2025) evolves code with a language model, and one of the things it sped up was a kernel used to train the very models it runs on. The Darwin Gödel Machine (2025) is a coding agent that rewrites its own source code, tests each new version on programming tasks and builds on the ones that work. The idea itself is older: Jürgen Schmidhuber’s Gödel machine (2003) rewrites any part of itself once it can prove the rewrite is an improvement; the Darwin version swaps the proof for testing.

A mind that works on itself needs three things:

  • A description of itself it can read. Lisp’s eval is written in Lisp: the system holds its own definition in its hands.

  • Safe, structural rewriting. Macros and edits to a tree, not text spliced together.

  • Failure that doesn’t wipe the state. A self-modifying system that crashes on a bad edit never gets to try a better one.

Lisp even drew the blueprint. In Brian Cantwell Smith’s 3-Lisp (1982) a running program can reach up a level into the interpreter that runs it and change how it is being run — a reflective tower. Back then it was a curiosity of programming-language theory. For a system meant to improve itself, it reads like a job description.

The Language Machines Will Write for Themselves

It’s not certain Lisp itself will win: a thin ecosystem and the inertia of habit. But the point is the form, not the specific language.

Today models write Python best, because Python is what people wrote the most of. That’s inertia, and human-era inertia at that. Once the main writer and the main reader of code is a machine that can produce its own training data, the size of the human corpus stops deciding things — the same way the price of memory stopped deciding things for Lisp.

So what does a machine want? A medium where a thought is an executable object; syntax so small its parser fits on a page; every edit a tree operation instead of a text diff; code that inspects and transforms code; failure as a fork in the road, not a catastrophe. If a neural network one day sets out to design a language for its own thinking — not for people, but for itself — it will most likely arrive at something very much like Lisp. Not out of respect for history, but because it will feel its way to the same properties.

Two honest objections:

  • Parentheses. Today’s models really do miscount closing brackets in Lisp. But that comes from writing a tree one character at a time: structure-aware decoding makes an unbalanced tree impossible by construction.

  • Thinking without words. SI may reason in vectors rather than words, and there are experiments with exactly that. Fine for the inner monologue. But whatever has to be executed, verified, shared or audited needs an explicit form, and with SI the audit is the whole point: researchers across the major labs argue that machine reasoning we can still read is one of the few safety handles we have. The most compact form that is both executable and readable by anyone, human or machine, is a tree written down as text. An S-expression.

Why C Won, Not Lisp

Short answer: C won not as a language for thinking, but as a language for the hardware of its era. The reasons were purely practical.

  • Closeness to the machine. C is essentially a thin, portable wrapper over the processor: manual memory management, no hidden machinery. The code is predictable and easy to map onto CPU instructions. On 1970s–80s hardware with a handful of kilobytes of memory, that was decisive.

  • Lisp demanded expensive things. Garbage collection, dynamic typing, working with trees in memory — all of it cost CPU time and memory that barely existed back then. What is free today was a luxury then.

  • C came bundled with Unix. The operating system itself was written in it, and the language spread along with Unix through universities and industry. That gave it a huge ecosystem and the status of a default standard.

  • Predictability over flexibility. Systems software — drivers, kernels, compilers — needs control and speed, not a program’s ability to rewrite itself. Exactly where Lisp is strong, the systems world didn’t need it.

Back then, choosing C was entirely appropriate. With memory and CPU scarce, manual control over the hardware wasn’t a whim but a necessity — the Lisp of those years simply had nothing to run properly on.

The next round went to Python, built on top of C and won on a different scarce resource: the programmer’s attention. Readable code and a library for everything mattered more than speed, and machine learning grew up in that ecosystem.

Each time, the winner was set by whatever was scarce: memory in the seventies, people’s time in the two-thousands. In the SI era neither is scarce. What is scarce is trust in code nobody has the time to read, because machines write it at machine speed. That’s an argument for structure: code as data that a machine can check, transform and reason about, and that a human can still follow.

Lisp was answering a question nobody was asking yet: what language does a mind need in order to work on itself? Now that question is on the table.

—Alex