Patrick Collison's Unpopular Opinion: The Best Code Is Written in Languages Most Developers Have Never Heard Of
Most developers write code the same way: type in an editor, run in a terminal, debug when things break. It's a cycle that's been with us for decades.
Patrick Collison thinks we're doing it wrong.
In a recent wide-ranging conversation, the Stripe cofounder made a provocative argument: the most productive development environments ever built—Smalltalk and Lisp machines—were abandoned in favor of something far inferior. And we're still living with the consequences.
The Problem with Modern Development
Here's the thing about your typical development workflow: it treats code as static text. You write it, you save it, you run it. When it crashes, you go back to the editor, make changes, and restart.
This seems normal. It's what everyone does. But Collison points out that it's remarkably inefficient.
The Smalltalk environment was different. It was a live system where you could pause a running program, inspect the state, change a line of code, and resume execution—all without restarting. The debugger wasn't a separate tool you invoked after something broke. It was the environment.
Think about that for a second. Instead of the edit-run-fail-debug loop that defines modern development, Smalltalk developers could fix problems in real-time while the system was running.
Why Did We Give This Up?
The conventional wisdom is that Smalltalk and Lisp were too expensive to maintain. They required specialized environments. They didn't play nice with version control systems built for text files. They didn't scale to modern team sizes.
Collison doesn't entirely disagree—but he thinks we gave up something valuable without fully understanding what we lost.
Modern development environments have gotten better in some ways. Git is powerful. Code review is valuable. Cloud-based IDEs are convenient.
But the fundamental workflow—write text, run text, debug text—is largely unchanged from the 1970s. We've added layers of tooling around the edges without changing the core experience.
The Real Cost of API Decisions
One of Collison's key insights: early technology choices have multi-decade consequences that are easy to underestimate.
Stripe's early use of Ruby and MongoDB made sense at the time. Ruby was fast to write. MongoDB was flexible. They could move quickly.
Fifteen years later, Stripe is still dealing with those choices. They've had to build extra infrastructure to handle reliability and performance. Some services have been rewritten in Java. They're undertaking massive API migrations to correct early abstraction decisions.
The lesson isn't that Stripe made wrong choices. It's that technology decisions are rarely temporary. They're more like instruction-set changes than product launches. Once you pick a path, you're often locked in for a decade or more.
This has implications for AI development. When everyone is rushing to ship features, who stops to think about what the API will look like in 2030?
What About AI?
Collison was asked whether current LLMs have produced measurable productivity gains in GDP. His answer: not evidently yet.
This might surprise anyone who's been following the AI hype cycle. We hear constantly about transformative productivity improvements. But the empirical data—so far—is mixed.
One theory is diffusion lag. It takes time for new technologies to work their way through the economy. Another is measurement problems. GDP captures some things well and others poorly.
Whatever the reason, Collison's take is notably grounded. He's not against AI—he's just skeptical of claims that don't hold up to scrutiny.
The Biology Angle
One of the most interesting parts of the conversation: Collison sees a breakthrough moment in biology, not just AI.
The combination of three technologies is creating something new:
- Sequencing gives us the ability to read biological systems at unprecedented resolution
- Deep learning provides the "think" capability—predicting how biological systems work
- Gene editing enables precise "writes"—actually modifying biological systems
Together, these form a closed experimental loop at the level of individual cells. That's something fundamentally new. It's not just faster biology. It's a different kind of biology.
What This Means for Developers
If there's a practical takeaway from Collison's thinking, it's this: think harder about your foundations.
Most development decisions are made quickly. Which framework? Which language? Which database? These choices feel routine. They aren't.
The cost of reversing a decision compounds over time. A hasty choice at the beginning of a project becomes a legacy burden years later.
This applies to AI decisions too. When you're building AI features, are you thinking about what the system will look like in five years? Or are you just trying to ship something now?
The best developers aren't the fastest coders. They're the ones who think carefully about what they're building and why—and plan for the long term.
That's an unpopular opinion in an industry that worships speed. Maybe that's why it's worth paying attention to.