Why Some Programming Languages Resist LLMs

Programming abstractions have always been a trade-off between expressiveness and clarity. Dijkstra argued convincingly that good abstraction lets us think clearer, say what's needed unambiguously, and no more than that. Formal languages by design cannot say a lot, but what they do say is absolutely precise. This observation sits at the heart of a growing question: as LLMs become capable of translating between languages, which notations remain genuinely easier to use directly than to prompt an LLM to work with?

The term "LLM-Complete" captures this property: if a language or task within a language is easier, more convenient, and preferable to express in formal notation than to ask an LLM to handle, then that language is more powerful as a knowledge tool. Conversely, if a language isn't LLM-Complete, it risks being thought of as "low-level" — fit only for generating and ingesting, a glorified boilerplate. This framing suggests that the next several hundred programming languages may not be about novelty so much as about which notations LLMs can reliably work with and which they cannot.

Formal Languages versus Natural Language Prompting

The article points to concrete examples that illustrate the gap. A function composition like f (a -> b) -> f b -> f a tells experienced developers quite a lot about what can and cannot happen. A regex like [a-z-]{2,3}$ is both shorter to digest and more precise: "a suffix consisting of alphabetical letters or a hyphen of length between 2 and 3." These notations say little in volume but say it precisely.

This raises a question about high-level languages: if there's ever a reason to prefer expressing code in plain English to an LLM and have that LLM act as a "compiler" into C, Rust, or TypeScript, might that indicate a failing of the language or its abstractions? For declarative, high-level aspirations, the gap between intent and implementation can feel like the language is doing too much heavy lifting.

When LLMs Become the Compiler

The piece notes that giants of computer science acknowledge the field is maturing, yet there remains a lot of work left to do. There aren't vocabularies or algorithms to describe many types of problems and behaviors we see in nature. This gap is precisely why the LLM-Complete concept feels urgent: if we cannot compute reliably, and if LLMs are increasingly what we reach for to bridge the gap, then which notations are we actually improving, and which are we merely papering over?

The article also references Peter Landin's paper "The next 700 programming languages," which predicted a move toward more compositional, denotational languages. Landin's forecast, made decades ago, now feels like a prelude to the current moment: if LLMs can serve as the bridge between notation and execution, then the number of viable notations may expand, but the criteria for what makes a notation worth using directly may shrink.

Esoteric Examples and the Limits of Language

For stylistic rather than technical reasons, the concept of "LLM-Complete" has been applied jocularly to esoteric language capabilities — Tetris-Complete, Pac-Man-Complete. These playful extensions acknowledge that the boundary between "fit for LLM work" and "not fit" can be pushed to absurd extremes, but they also underscore a real point: some tasks sit so far outside conventional language design that even an LLM struggles, and formal notation may be the only reliable path forward.

The article also quotes Alan Kay's observation that software culture is a pop culture; we don't know our own history. This lack of historical awareness means many developers encounter the same tension between natural-language prompting and formal notation without recognizing it as a recurring theme across decades of language design.

What This Means for Developers

For any given task, the LLM-Complete question breaks down like this: if expressing a problem in the language's native notation requires fighting the abstraction, it may be more efficient to let the LLM handle the translation. If the notation is precise, concise, and already close to the problem's shape, keeping it formal may avoid the overhead of prompting, verifying, and correcting an LLM output.

The article's central tension — that we equate language capability with intelligence informally, and that this equating shapes which tools we trust — matters because it determines whether a developer reaches for a keyboard or a prompt box first. As the piece suggests, the next 700 programming languages may ultimately be about settling which tasks each format handles best, and where the boundary between them lies.

Learning how these services and tools work on a technical level remains valuable regardless of mood around LLMs. The technical details of how models parse, generate, and translate code affect every interaction, and understanding those details helps decide when to trust the model and when to fall back to the notation itself.

f (a -> b) -> f b -> f a
[a-z-]{2,3}$
  • Dijkstra on abstraction: let us think clearer, say what's needed unambiguously, and no more than that
  • LLMs provide compelling evidence that language is profoundly important (or that we think it is)
    • > Formal languages can't say a lot by design, but what they do say is absolutely precise
  • The absolute enraptured fascination with LLMs proves people equate language capability with intelligence
  • As Alan Kay derides, software culture is a pop culture; we don't know our own history
  • Peter Landin's paper "The next 700 programming languages" predicted a move toward more compositional, denotational languages