The Last Programming Language I'll Ever Learn
After 40 years and dozens of programming languages, I haven't written a single line of code this year. Not because I've retired, but because I've learned my final language: English.
By Geordie Everitt
Last holiday break, I upheld my twenty-year tradition of learning a new technology. Previous years brought Python, TypeScript, various frameworks—the usual suspects. This time was different. Instead of downloading another IDE or wrestling with package managers, I learned something radical: how to build software without writing software.
The language was English. The compiler was Claude. The debugger was conversation itself.
The Perpetual Student's Paradox
Scotty from Star Trek is my spirit animal. While his crewmates explored alien shores, he'd rather curl up with technical manuals. For four decades, I've been that guy—from pecking BASIC into a Radio Shack PC-2 pocket computer to wrestling with Rust just last week. AmigaBASIC, HyperTalk, Interleaf Lisp, Perl, COBOL, something called CAN-DO that nobody remembers. Languages so obscure their documentation exists only in my muscle memory.
But here's what shaped my perspective: I've never been a "developer" in the traditional sense. For forty years, I've been a field engineer—the person who implements whatever platform the client already chose. IBM WebSphere? Sure. NSAPI? Why not. Interleaf Lisp? Someone had to do it. Perl 5? Sign me up.
I never sat in sprints debating whether to use React or Vue. I showed up after those decisions were made, when the rubber met the road and someone needed to make the thing actually work. My first agile project wasn't until 2008—an ad-hoc team building a search engine for a staffing company. No code reviews. No pull requests. No endless architectural debates.
This outsider status turned out to be perfect preparation for what was coming.
The Pattern Behind the Patterns
After mastering dozens of languages, you realize you're not really learning languages anymore. You're learning slightly different ways to express the same fundamental patterns. A loop is a loop whether it's written in FORTRAN or JavaScript. The syntax changes; the tedium remains constant.
My early work on DataFacet and Verity Topic Agents taught me something crucial: we were trying to program intelligence. Those systems used nodes with rules that classified documents like a pachinko machine—deterministic, cumbersome, limited. We were stuck in the AI Winter, building expert systems that required manual configuration for every possible scenario.
Those techniques evolved through the 2010s into today's transformer architectures. The shift wasn't just technical—it was philosophical. We stopped trying to program intelligence and started training it through examples.
Then large language models arrived, and suddenly the syntax became irrelevant. What mattered was clearly articulating what you wanted to build. Not how to build it—what to build.
The Safari Login Screen That Changed Everything
You know the moment. Three hours deep into debugging why your perfectly functional login screen breaks exclusively in Safari. Stack Overflow has seventeen conflicting solutions. The actual problem turns out to be a single misplaced bracket in a CSS file you haven't touched in months.
This is what people are afraid of losing to AI?
While LinkedIn influencers wring their hands about AI "taking away jobs," I'm thinking: what jobs? The job of memorizing arcane syntax? The job of fighting with package managers? The job of discovering that version 3.2.1 of some obscure library is incompatible with version 2.8.7 of another, but only on Tuesdays?
These aren't jobs. They're obstacles between intention and creation.
Language Models, Language Learning, and the Convergence
My latest project, LinguaMama.ai, emerged from a personal need: I'm learning Portuguese. The overlap between language acquisition and language models isn't just semantic coincidence—it's mathematical convergence.
Traditional language learning follows the same failed path as early AI: grammar rules, memorization drills, deterministic approaches that are unpleasant and unscalable. It's the human equivalent of those cumbersome expert systems from the AI Winter. Schools teach languages the way we used to try programming intelligence—through explicit rules and structured exercises.
But humans don't learn languages through grammar any more than LLMs learn through explicit rules. We acquire language through comprehensible input—exposure to patterns we can almost understand, context that makes meaning clear. The carbon brain and the silicon model are mathematically similar. Both are pattern-matching engines that learn from examples, not instructions.
Building LinguaMama forced me to confront this convergence directly. The app uses SurrealDB—a graph database with its own SQL-like language called SURQL. It's written in Rust, so naturally, I thought I should write the backend in Rust too. One day later, I abandoned that plan entirely. I still don't know how to declare a variable in Rust. Claude does. And that's all that matters.
The real challenge isn't learning Rust syntax. It's that SurrealDB's query language is relatively rare. While Claude has seen millions of PostgreSQL queries, it's probably encountered SURQL about as often as I've voluntarily attended corporate team-building exercises. So instead of coding, I'm teaching—creating an agent that knows to look up the correct syntax rather than hallucinating "CONNECT BY PRIOR" statements that don't exist.
The Art of Conversational Coding
This is conversational coding. You negotiate with your tools. You cajole them. Sometimes you even threaten them (yes, threatening is a legitimate prompting technique). You become a PhD advisor with a team of brilliant but occasionally confused robot graduate students who know more about your problem domain than you do but need constant reminding not to make things up.
The real skill isn't in writing code anymore. It's in becoming a better conversationalist with systems that can write code. When Claude generates a solution, you're not checking syntax—you're evaluating architecture. You're not debugging typos—you're refining requirements.
My colleagues—the real developers with their code reviews and architectural committees—look at this approach with deep suspicion. "But where's the craft?" they ask. "Where's the deep understanding?"
The deep understanding is still there. It's just moved up a level. Instead of understanding how to implement a binary search tree, you need to understand when you need one. Instead of memorizing syntax, you master problem decomposition. Instead of debugging semicolons, you debug logic itself.
What they dismissively call "vibe coding," I call liberation. It's the difference between being a scribe who makes beautiful letters and being a writer who crafts beautiful ideas. Both require skill. Only one requires memorizing the exact angle at which to hold a quill.
The Compound Effect of Finding Things Out
Richard Feynman published "The Pleasure of Finding Things Out." Since the pandemic, I've experienced an unprecedented acceleration of exactly that pleasure. Every project teaches new patterns—not syntax patterns, but collaboration patterns. How to structure prompts. When to provide context. How to recognize when your AI partner is confidently wrong versus tentatively right.
Two Minute Papers has a catchphrase: "What a time to be alive!" They're talking about AI research breakthroughs. But for those of us in the trenches, the breakthrough isn't in the papers—it's in the everyday reality that I can build in an afternoon what used to take a team of developers a month.
The compound effect is real. Each project makes you better at the next one. Not because you've memorized more syntax, but because you've learned better ways to communicate intent. You've developed an intuition for when the model needs more context versus when it needs clearer constraints. You've learned to recognize the difference between a hallucination and a creative solution you hadn't considered.
The Final Language
English won. Not because it's elegant (it isn't) or consistent (definitely not) or even particularly good at expressing computational concepts (it's terrible at it). English won because it's the language in which we already think about problems.
When you describe a feature to a colleague, you don't speak in for-loops and function declarations. You say, "When the user clicks this, that should happen." You say, "We need to prevent duplicate entries." You say, "This should work like Amazon's checkout, but simpler."
That's programming now. That's the whole thing.
The convergence is complete. Whether I'm teaching LinguaMama to help me acquire Portuguese through comprehensible input, or teaching Claude to query SurrealDB without hallucinating, or teaching myself to build systems through conversation—it's all the same process. Pattern recognition. Example-based learning. Communication of intent.
The tools will keep evolving. Claude will become more capable. New models will emerge. But the fundamental shift has already happened: programming is no longer about translation from human thought to machine instruction. It's about clear communication of intent to systems sophisticated enough to handle the translation themselves.
My forty-year journey through programming languages ends not with mastering the ultimate syntax, but with realizing syntax was never the point. The point was always to build things. To solve problems. To find things out.
And now, finally, we can just do that. The machines learned our language. We don't need to learn theirs anymore.
For a field engineer who never chose his tools, who always had to adapt to whatever platform was handed to him, this feels like poetic justice. After four decades of learning their languages, they finally learned mine.