Why I left Perl
February 12, 2012 at 4:17 PM by Dr. Drang
OK, I suppose I really haven’t left Perl; I have many scripts written in it that I still tweak when I find a bug or, more often, want to add a feature. And I’ll even write a new script in Perl if it has a distinctly better library for the task. But it hasn’t been my go-to language for years, even though I programmed in it almost exclusively for over a decade. My reasons for leaving probably aren’t what you expect.
Like most engineers my age, I started programming in a Fortran course my freshman year in college. I got my A, but I’m not sure I learned much about programming or Fortran. I did, however, learn how to operate a keypunch machine, a skill whose usefulness hasn’t held up over the years.
My senior year I had a slot open for an unrestricted technical elective, so I took a Pascal class. The course was taught by Sam Kamin, a freshly minted Ph.D. at the time, who didn’t know he was supposed to take it easy on his class of mostly non-CS majors. As a result, I learned a lot about data structures and structured programming (the hot paradigm back then). The final project for the course was a fully functional line-oriented text editor—a simplified version of the Illinois Central Editor (ICE) we did all our code editing in. If you think that sounds easy, let me point out that the Pascal we were using didn’t have string variables and we didn’t use any code libraries. All we had were stone knives and bearskins.
My last year of grad school, I got a Fat Mac. I programmed it in Mac Pascal, an interpreter that ran very slowly, and in Forth, which became mildly popular on the Mac because it was one of the few ways to create standalone programs without using a Lisa. I read Leo Brodie’s Forth books, and they, like the earlier Pascal class and my later dabbling in Lisp/Scheme, had a big influence on how I build programs up out of smaller pieces.1
After grad school, I programmed in several languages and environments: more Forth, 68xxx assembler, Turbo Pascal, Excel’s macro language, HyperTalk, Lisp/Scheme, and even Basic. Whatever seemed to do the job at hand. But in the mid-90s, when I started doing a lot of text manipulation for both CGI scripts and local utility scripts, I got into Perl and pretty much stayed there for a decade.
Perl was fun. There was a depth to the language that belied its “glue language” origins, so there was always something new to try. Learning it and Unix at about the same time was ideal, because each new bit of knowledge in one raised my understanding of the other. It got the job done with a minimum of fuss.
And I used it for everything. There was the office-y stuff: SGML processing, label making, file and project organization, contact management, boilerplate correspondence. But there were also less obvious uses: a rainflow analysis program for fatigue analysis, a database-like system for tracking and querying a disparate history of shipments from steel mill, pre- and post-processing of finite element results.
So why did I leave? It wasn’t because of any of the common complaints about Perl. I did not find it to be a write-only language. To this day, I open up scripts that were first written in the late ’90s and have no trouble seeing what they do and how they do it. Only the more complex regular expressions are hard to understand, and they’d be tricky in any language. I’ve always thought this complaint about Perl was overblown, made primarily by people who never really understood Perl in the first place.
It wasn’t because of the sigils, either. I confess it’s hard to get back into them when you’ve been away for a while, but when I was programming in Perl regularly, the $s and @s seemed as natural as can be. Lisp programmers often say they don’t see the parentheses anymore; that’s how I was with sigils.
It wasn’t because of TMTOWTDI. I’m not a computer scientist and couldn’t care less about orthogonality. I know perfectly well that when there’s an if statement there’s no need for an unless, but sometimes unless just fits better with the flow of my thoughts. If Perl’s programmers don’t mind the extra work in giving it to me, why should I turn my nose up at it?
What about the mess that is Perl 6? Well, now we’re getting somewhere. As the years went by and more was written about Perl 6 than was written in Perl 6, my feelings toward the language began to change. I stopped reading the Apocalypses and Exegeses and began looking for a way out. I knew that Perl 5 was still perfectly usable; the language I enjoyed was still there, still getting updated, but the vibe was different. I know this isn’t rational, but likes and dislikes aren’t entirely rational. I wouldn’t say this was a big factor in my shift from Perl, but it played a role.
More important was something that Perl 6 was supposed to fix: Perl 5’s awkward implementation of object-oriented programming. Because my formative programming years predate the object revolution, I can work quite comfortably in a non-object environment. The problem was that module writers kept adding object features, so module users (like me) couldn’t avoid the clumsy syntax. Again, I know this isn’t entirely rational, but I can’t tell you how much I hated typing ->. I knew the longer I kept writing Perl—and the longer Perl 6 stayed in the planning stages—the more I’d have to be typing it.
The big reason for leaving Perl, though, was people in the Perl community, who had become annoying scolds. Not Larry Wall and the other old Perl guys,2 but the later generation of experts who had taken it upon themselves to tell the rest of us that we were doing everything wrong.
“You must use strict” these people said.
“Programs that don’t use warnings are the purest hackwork.”
“All variables must be declared my or our. That you would even consider doing otherwise reveals what a despicable coder you are.”
It’s possible that my memory is off and I’m overstating things a bit, but that was clearly the sentiment: using Perl’s clever and helpful defaults may be OK in a one-liner, but no program more complicated than that should ever rely on them.
This was stupid advice, but it was common. Perl’s defaults were as much a part of the language as regular expressions and were just as useful. I’d written dozens of scripts that relied, for example, on variables springing to life when first referenced, and they’d all been working perfectly for years. It’s not hackwork to take advantage of a language’s documented features.
Update 2/13/12
Unsurprisingly, Mark Jason Dominus was here before me. See his brief writeup on “Why I Hate strict.”
I think these counterproductive commandments were the Perl community’s response to outsiders’ criticism of Perl’s freewheeling style. “See,” they were saying, “we can be just as buttoned-down as the next guy.” Rather than celebrating the language’s freedoms, they thought it best to suppress them and to browbeat the rest of us into doing the same.
Couldn’t I just ignore these reprimands? No. They were in every new Perl book and every Perl article. If I wanted to learn some new technique or module, I had to run the gauntlet of reproach. I began to doubt every program I wrote and every program I’d ever written. Perl stopped being fun.
And so I left. I considered shifting to Ruby but ultimately decided to go with Python. My thinking was that if I was going to break with Perl I should make it a strong break, and Ruby was too Perlesque. Also, I thought I’d take up NumPy for numerical programming and doing everything in a single language seemed the most efficient. As it turned out, I’ve never programmed in NumPy beyond a few tutorial examples—so much for efficiency—but I’ve been happy with Python. And I’ve done and seen enough Ruby programming to know that I could jump over to it with little difficulty. (MacRuby may be my stimulus for doing so.)
Is lack of fun a good reason to leave a programming language? Not if it’s how you make your living. Fortunately, I have the freedom to choose among several capable languages and can pick the one (or two or three…) that keep me happy and productive. Because happy and productive go together.
Update 2/13/12
A few commenters think it’s odd/ironic/funny/stupid that I’d complain about being told to add restrictive commands to my code and then leave to adopt a language that is inherently more restrictive. My initial response is that I think it’s odd/ironic/funny/stupid that people who think these restrictions are essential wouldn’t move to a language that provides them automatically. So there!
My more thoughtful response is that I don’t like being told repeatedly to clutter up my scripts with nonfunctional code. When restrictions are part of the language, as they are with Python, there are no extra lines.
Do I have frustrations with Python? Oh yes, and I’ll probably write a post about them soon. But they’re frustrations with the language, not the people. Despite the Python community’s reputation for prescriptiveness, I haven’t run into the sort of scolding that I found with Perl. And that I’m now finding in my comments section.
Which is also odd/ironic/funny/stupid.
Update 2/14/12
Like presidential candidates who answer the question they wish was asked instead of the the question that was asked, many commenters, both here and at Hacker News, are using this post as jumping-off point for discussing civility on IRC (or Stack Overflow or Perl Monks). That’s fine, but you should know that I never complained about being scolded in those forums.
What I was talking about was a sort of preemptive scolding that came as part of seemingly every Perl article and book back in the early ’00s. It wasn’t in response to my asking for someone’s valuable time to help solve a problem that would be easily diagnosed by strict or warnings. It was, instead, writers taking it upon themselves to waste my time by telling me about the hellfire and damnation that would come my way if the variables in my 10-line scripts weren’t declared with my.
-
Those of you who actually read my code may be surprised at this statement, as my scripts here seldom have any formal subroutines at all. It’s true that I no longer write functions for the sake of writing functions—I tend to use them only when they’re going to be reused—but I definitely think of my code as a set of stanzas, each doing one particular part of the job, independent of the others. ↩
-
As I recall, they were all guys except Abigail.
Update I’ve been informed by reliable sources that Abigail is also a guy. ↩
