I think it was the semester's first career fair, during my sophomore year in college. A Microsoft recruiter, screening for computer science majors, pulled me aside and asked me what my "favorite language" was. I panicked, and told them that, uh, I sorta liked English.

I was reminded of this silly incident when coming across this article a few months back about, of all things, the programming language Perl:

Programmers Aren’t So Humble Anymore—Maybe Because Nobody Codes in Perl

Perl is a messy, maddening programming language, the “duct tape of the internet.” But at least you can tell it was made by humans.

WIREDSamuel Arbesman

For those not exposed to web development in the late '90s, Perl was the most popular language for building websites during those early years^[1]. It was a messy language, a dense mixture of ASCII symbols and keywords with few guardrails on code structure. By the 2000s, Perl lost its popularity in web development to the likes of PHP and Ruby, though it has retained its usage as a scripting Swiss-Army chainsaw.

TMTOWTDI

One aspect of Perl, though, deserves attention: its motto, "There's More Than One Way to Do It" (TMTOWTDI, pronounced "Tim Toady"). This was a core design philosophy from its creator, Larry Wall. He modeled his programming language in the same vein as human languages. In particular, he appreciated the richness and the sheer variety of ways that human languages have of expressing similar ideas, and their tendency to evolve over time based on speakers' needs and experiences. The result is communication that is inconsistent, messy, but also multi-layered and expressive and individual.

Linguistics drove Perl's development direction. For instance, the language features multiple syntaxes for the same operator; many overlapping functions to manipulate strings based on emerging needs; a whole bevy of selectors and patterns for regular expressions. Its package manager, CPAN, is gloriously organic in breadth and scope, well before Node's npm took the crown. In providing a breadth of keywords and grammars, Perl invites developers to use whatever formats they prefer. This was, and still is, a fairly rare programming language design principle.

A major part of Computer Science and coding school curricula revolves around understanding how machines execute, the specificity and deterministic behaviors that drive computing. Every programmer remembers the first time their machine is doing what it's told, not what they meant.

Compare Perl's free-wheeling formatting to languages like Java or Golang. The former spawned a popular variant, Java EE, meant for enterprises to build web applications at scale, while the latter promotes tooling to standardize formatting as a best practice. Yes, the machines execute instructions all the same, but it's easier for programmers to read and understand the code when the language provides an unambiguous, straightforward syntax. We learned that when teams of programmers collaborate, it's rarely productive to spend time debating personal formatting preferences and syntactic quirks.

More Than One Way to Vibe Code

LLMs are bringing back TMTOWTDI.

Vibe coding is this phenomenon of building software by describing functionality in prose, then relying on the LLM to understand the task and write the code. For non-programmers, this bypasses many of the traditional and technical steps of learning how to code. You can, realistically and actually, create functional software without knowing the syntax of a programming language; you can skip foundational computing concepts altogether.

Freed from the constraints of programming syntax, we're coding with actual human language, with all its ambiguity and looseness and inferences based on our own experiences. For example, these four prompts may well build the same app:

• "Build a todo list app."
• "Create a simple web app where I can add tasks, mark them done, and delete them."
• "I need something to track my daily tasks, show me what's pending, and let me clear the ones I've finished."
• "Make me a personal productivity tool with a clean interface for managing things I need to get done today."

AI agents are a spiritual successor to Perl.

Lessons from History

But, Perl's rise and fall also holds a cautionary tale. The downside of enabling permissive, almost individualist coding is that it's really hard to understand afterwards^[2]. Programmers have plenty of quips about the tedium of reading Perl code: "write once, read never," or "write-only code." The language fell out of favor for web development in part because server code needs to be maintained.

I'm wary of the same problems with vibe-coded systems. Without overarching architecture and technical plans, each piece of LLM-generated code is created in isolation, and the entire system is brittle. When there are no easy ways to evolve the system, tech debt accrues and changes easily break functionality. Some engineers admit that they are not reviewing AI-generated code, because it's harder to make sense of its structure—unsurprising, when there is none—and it also takes a lot more effort to retroactively apply structure to giant piles of already-written code.

Maintenance is already difficult when the code is piecemeal; it's impossible when the developer cannot read the output.

Other languages eventually superseded Perl for web development, but it's more accurate to say that the deciding factor was the emergence of web development frameworks: CakePHP, Zend, Django, Ruby on Rails, etc. Many of these frameworks sold developers on their highly opinionated structure; they implemented variations of the Model-View-Controller (MVC) development pattern borrowed from desktop applications. This was the complete opposite of TMTOWTDI, but it's a pattern that has persisted across generations of development, from desktop to web to mobile.

I anticipate LLMs following the same trajectory. Already, vibe coders are figuring out that they get more consistent output and better quality code when they are more specific about requirements up front. I'm noticing engineers experimenting with lengthy templates and step-by-step plans, so coding agents have the necessary structure to build with architectural intentions. Inventing and refining frameworks may well be what saves us from the sloppiness of AI-generated code.