Daniel Haskin was excited. Like thousands of other software developers, he’d been riding the wave of AI-assisted coding tools — GitHub Copilot, ChatGPT, Claude — watching them transform how he wrote Python, Go, and other mainstream languages. The productivity gains were real and sometimes staggering. Then he sat down to write some Lisp.
Nothing worked.
Not in the way he expected, at least. The AI models that could fluently generate pages of Python or JavaScript stumbled, hallucinated, and produced nonsensical output when asked to write in one of computing’s oldest and most intellectually revered programming languages. In a blog post titled “Writing Lisp is AI-Resistant, and I’m Sad,” Haskin laid out his frustration with an honesty that resonated across the programming community. “I’ve been writing a lot of Lisp lately,” he wrote, “and I’ve been trying to use AI to help me. It’s been a disaster.”
His experience isn’t an edge case. It’s a window into one of the most underexplored limitations of the current generation of large language models: they are, by construction, reflections of the internet’s most popular languages, frameworks, and idioms. Languages that dominate GitHub repositories and Stack Overflow threads get excellent AI support. Languages that don’t — no matter how elegant, powerful, or historically significant — get left behind. And that asymmetry is starting to reshape which tools developers choose, which communities grow, and which traditions quietly fade.
Haskin’s specific complaints are instructive. He found that AI models would generate Lisp code that looked superficially correct but was riddled with problems: wrong function names, invented APIs, confused syntax between different Lisp dialects. Common Lisp, Scheme, Clojure, Emacs Lisp — the models seemed to blur them together, producing a kind of statistical average of “Lisp-like” code that didn’t actually run in any specific implementation. The parentheses were there. The structure was roughly right. But the details were wrong in ways that took longer to debug than writing the code from scratch.
This is the cruel irony. Lisp, a language family dating back to 1958 and designed by John McCarthy at MIT, was literally created to do artificial intelligence research. It was the dominant language of AI for decades. And now the latest AI systems can’t write it properly.
The reason is straightforward, if dispiriting. Modern large language models learn by ingesting vast quantities of text from the internet. Python dominates public code repositories. JavaScript is everywhere. Java, C++, TypeScript, Go — all massively represented. But Lisp dialects? Their footprint online is comparatively tiny. According to the 2024 Stack Overflow Developer Survey, Clojure — the most popular modern Lisp — is used by roughly 1.5% of professional developers. Common Lisp and Scheme register even lower. The training data simply doesn’t contain enough high-quality Lisp code for models to learn the language’s nuances, its idioms, its standard libraries.
And Lisp is a language where nuances matter enormously.
Unlike Python, where there’s typically one obvious way to do things (as the Zen of Python prescribes), Lisp is a family of languages built around the idea of malleability. Programmers routinely extend the language itself using macros — code that writes code. A seasoned Common Lisp developer’s codebase might use domain-specific constructs that look nothing like textbook Lisp. This is the language’s greatest strength and, in the age of AI, its greatest vulnerability. Models trained on limited data can’t learn patterns that are, by design, unique to individual projects and programmers.
Haskin’s post struck a nerve because it articulated something many niche-language programmers had been feeling but hadn’t fully named: the AI productivity boom is not evenly distributed. It’s a phenomenon concentrated in a handful of mainstream languages, and it’s creating a widening gap between the “AI-rich” and the “AI-poor” corners of software development.
The Feedback Loop That Could Kill a Language
This gap has consequences that extend well beyond individual frustration. Consider the economics. A Python developer using Copilot can, by some estimates, write code 30-55% faster than without it, according to research published by GitHub’s own research blog. That’s a massive productivity advantage. If you’re a startup founder choosing a technology stack, or a CTO hiring engineers, the calculus has shifted. Choosing a language with strong AI tooling support isn’t just a matter of preference anymore — it’s a competitive advantage measured in shipping speed and engineering headcount.
This creates a feedback loop. Fewer people choose Lisp for new projects. Fewer new Lisp codebases appear on GitHub. Less training data becomes available for future models. AI support for Lisp gets worse relative to mainstream languages. Fewer people choose Lisp. The cycle repeats.
It’s not that Lisp is dying — communities around Clojure, Common Lisp, and various Scheme implementations remain active and passionate. But the gravitational pull of AI-assisted development is real, and it’s pulling developers toward languages where the tooling works best. Haskin himself acknowledged this tension. He loves Lisp. He finds it a more expressive, more enjoyable way to think about programming. But he’s watching the practical gap widen with every model update that improves Python generation while leaving Lisp essentially untouched.
The problem isn’t limited to Lisp. Developers working in Haskell, OCaml, Erlang, Forth, Ada, and dozens of other less-common languages report similar experiences. AI models can produce passable code in these languages for simple tasks — sorting algorithms, basic data structures — but fall apart when asked to do anything involving the language’s specific standard library, package management conventions, or idiomatic patterns. The models are, in effect, performing a kind of sophisticated translation from their internal representation of “programming” (which is dominated by Python/JavaScript patterns) into the surface syntax of the target language. The syntax comes out right. The semantics don’t.
Some researchers are exploring ways to address this. Fine-tuning models on curated, high-quality datasets for specific languages is one approach. The challenge is that creating such datasets requires exactly the kind of expert human labor that AI tools were supposed to reduce. Another approach involves retrieval-augmented generation — feeding the model relevant documentation and code examples at query time — but this adds complexity and doesn’t fully solve the problem of models that lack deep structural understanding of a language’s idioms.
There’s a philosophical dimension here too. Lisp’s design philosophy has always been about giving the programmer maximum power and flexibility. Paul Graham famously argued in his essays that Lisp’s power came precisely from its ability to be reshaped by the programmer. Macros, homoiconicity (the property that code and data share the same structure), and a minimal core syntax — these features make Lisp extraordinarily expressive for humans who master it. But they also make it extraordinarily difficult for statistical models to predict, because the patterns are less repetitive, less standardized, less… predictable.
In a strange way, the features that make Lisp powerful for human thought make it resistant to machine pattern-matching. The language is too flexible, too varied, too dependent on context and convention rather than rigid syntax rules. Python’s enforced indentation and relatively constrained syntax make it easy for models to learn. Lisp’s anything-goes expressiveness makes it hard.
So where does this leave the Lisp community? Haskin’s sadness is genuine, and it’s shared. There’s no easy fix on the horizon. The major AI labs — OpenAI, Anthropic, Google DeepMind — are focused on the languages that serve the largest user bases, which makes business sense but offers cold comfort to developers who chose their tools for reasons beyond popularity. Some Lisp developers have responded by building their own specialized tools, fine-tuning open-source models on Lisp codebases, or creating better integrations between AI assistants and Lisp development environments. These efforts are admirable but small-scale.
The deeper question is whether the current AI moment represents a temporary disadvantage for niche languages or a permanent structural shift. If AI coding tools continue to improve primarily for mainstream languages, the gap could become self-reinforcing and essentially permanent. New programmers, raised on AI-assisted development, may never encounter Lisp at all. The language that birthed AI research could become a historical curiosity, studied in computer science courses but rarely used in production.
That would be a loss. Not a catastrophic one — software will continue to get written, problems will continue to get solved. But something valuable would be diminished: the idea that a programmer should have access to the most powerful abstractions possible, even if those abstractions are unfamiliar to the mainstream. Lisp has always represented that idea. It’s always been the language that whispered: there’s a better way to think about this.
AI can’t hear that whisper. Not yet. And Daniel Haskin, sitting at his keyboard, parentheses flying, is writing his code by hand. The old-fashioned way. The human way.
He’s sad about it. He probably shouldn’t be.
WebProNews is an iEntry Publication