John Melesky

This entry was originally posted on February 7th, 2003 (honestly, check the wayback machine). It was the most popular of my articles at the time, but fell off the web when my site went down temporarily. Now it’s back. The formatting has changed, and some links have been updated, but it is otherwise uncut.

Perl. I really dislike Perl. I also get my paycheck by programming in it, so i force myself to deal. But i really dislike it.

The typing system is bad, but i can deal with it (though whenever i move back to another language, i have to shake off the desire to look for $@% tokens). The object system is a horrid hack, but it (mostly) works, and it supports important (to me) bits like multiple inheritance. The feature bloat of the core language and the syntactic cruft that goes along with it is terrible, but again i can overlook that.

But the general syntactic bloat is a different story. The TMTOWTDI self-righteousness (and the community self-righteousness in general, though that’s a different rant) is not only completely unfounded, but downright harmful to the development of programming skill over time.

They say that the syntactic richness allows programmers to express themselves richly, and appropriately to the topic at hand. They say that you should only need to learn a single programming language that can express anything that you might want. They say that it allows discipline without requiring external barriers to creativity. They say that writing Perl is like writing poetry.

Bull. All of it.

Learning new programming languages is not some sunken cost with no benefit. It’s a way to gain different perspective of problems, and to improve your ability to conceptualize solutions. When you learn a different language, you don’t just learn new syntax (or, at least, you shouldn’t)—you learn the language’s paradigms. Programming in a logic/constraint language is fundamentally different than programming in an imperative language, which is in turn different from programming in a functional language. Of course, everyone knows that—i’m not saying anything new. But the laziness so admired by the Perl community convinces otherwise reasonable people that there is no such need to learn new stuff—all languages are just feature sets, so let’s just import (sort of) those features into Perl, and we’ll be just as well off. So a generation of programmers grows up thinking that OO programming languages are fine with list and associative array data structures that aren’t full-fledged objects, currying of functions is supposed to be really hard and not very useful, logic is comprised of using “and” and ”||” in very large if-statements, and, look! you get formats, too!

That short-sited-ness doesn’t end with fundamental language features. POD is not literate programming. Strong regular expressions are not full-featured text-processing tools.

The “syntactic richness” obscures problems instead of providing more ways of solving them. Ideally, as your programming skill improves, you become aware and capable of thinking about programming problems at higher and higher levels of abstraction, dealing with wider swaths of code at once. As Perl programmers increase their skill, they become more and more concerned with the minutia of syntax—spending time “expressing themselves creatively” instead of gaining a broader perspective on architecture and design. They spend time making the lives of their coworkers more difficult rather than figuring out ways to make the whole development process easier. In short, the more experienced a Perl programmer you are, the worse a programmer you are in general (i’m obviously generalizing here, but still). Programming becomes not akin to structuring and writing ever richer and more nuanced pieces of literature, but to spelling the same labored stories in less and less readable ways (yes, you can spell “fish” “fish”, but also ”ghoti”, or “fic”, or “gheess” (which is reminiscent of “geese”, which eat fish, right? so it’s related literarily, right?), or even “fs” (if you use the implied vowel and set the lisping flag—and look! only two letters!)).

Perl programmers, you’re not poets. Poets don’t cut-and-paste documentation to minimize usefulness. Poets don’t cargo-cult code that they don’t understand, but which they know works in certain conditions. Poets aren’t poets because they can’t be bothered to write prose. Poets can write clear and lucid prose before they turn their pen towards verse—craft comes before art. And craft is not for the lazy.

Perl is ultimately useful only as a masturbatory language, ideal for perversities in the same way that INTERCAL or Dis are. Stop killing kittens.