Programmer Musings

Perl != Regular Expressions

Yesterday, I wrote an essay on a comment made in Jeff Atwood's Coding Horrors blog about regular expressions. While Atwood spends quite a bit of time on the two problems joke and talks passionately about regexes as a tool, he does take a swipe at the Perl programming language that seemed somewhat uncalled for.

I have seen Perl bashed by lots of people over the years. Some have never written (or read) any Perl, but still feel qualified to bash the language. I've also been told that the only reason that I could possibly like Perl is if I had not written or maintained anything serious in Perl. When I point to large applications running in a 24/7 data centers that I worked on for years, they normally change the subject. Pointing to the number of financial institutions, research groups, and large corporations that depend on Perl to function is also illuminating.

Regular Expressions

I often see regular expression bashing and Perl bashing tied together. There seems to be this weird meme running around that regexes are the only tool in the Perl toolbox. Both Atwood and Zawinski (see Atwood's post that started this line of thought) seem to take the viewpoint that Perl is nothing but regexes or that Perl somehow forces you to to do everything through regexes.

Anyone who has worked with Perl for very long has seen that the language has very strong support for regex processing. This makes sense because the original goal of the language was text processing and regexes are made for text processing. For many, Perl was their first introduction to industrial strength regexes. Maybe it's not too surprising that they decided to overuse that powerful little tool.

Perl is also a general purpose language that supports OOP as well as a procedural style. It also supports list processing and functional programming. There are modules on CPAN for controlling hardware, accessing databases, biology, and astronomy. There are also natural language processing modules, XML parsers, and web frameworks.

Perl is a powerful, flexible language that some of us use to get actual work done.

Passionate About Perl

As much as some people hate Perl and find it necessary to build up their language of choice by bashing Perl, some of us find the language to be a natural tool for many jobs. I have worked professionally in half a dozen general purpose languages over my career. But for solving a problem quickly, I normally turn to Perl. And I don't just mean for quick and dirty scripts. If I need to solve something in a short period of time and be sure it will work for years, I also often use Perl.

Bjarne Stroustrup once said:

There are only two kinds of programming languages: those people always bitch about and those nobody uses.

I would say that both C++ and Perl definitely fall into the first category.

People often pick on other languages. We've all heard the complaints (that are at best half true). Almost everyone picks on Basic for being a bit of a kiddie language. Cobol is the old-style business language that rots the brain. C++ is too baroque. Python is obsessed with indentation. Lisp has too many parentheses. Staticly typed languages are too obsessive and dynamic languages are either too slow or too loose.

Although the fans of each language might insult other languages in a friendly sort of way, mention Perl and the vitriol begins to fly. I know quite a few people who really like Perl and I know at least as many who truly hate it. As Kathy Sierra pointed out a few years ago If some people don't HATE your product, it's mediocre..

Based on the level of hate that the Perl programming language seems to inspire, it's safe to say that the language is definitely not mediocre.

Regular Expressions as a Problem

Jeff Atwood had an interesting post on regular expressions a few days ago. Most of the article talks passionately about the usefulness of regular expressions, strategies for writing readable regular expressions, and tools to help write and debug regular expressions.

Along the way, Jeff points out a comment that usually pops up when the topic of regular expressions appears:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

The post points to some interesting further research on the quote and then gets down to the meat of his regular expression advocacy. But not before taking a swipe at the Perl programming language with:

Should you try to solve every problem you encounter with a regular expression? Well, no. Then you'd be writing Perl, and I'm not sure you need those kind of headaches.

I know I shouldn't be, but I'm continually surprised by how many people really seem to dislike Perl.

The Two Problems

First off, I have to say that I do find the two problems quote to be amusing and somewhat clever (at least, the first time I heard it). According to Jamie Zawinski, who originated this version of the quote, he got it from another version before that used sed instead of regular expressions. Honestly, you could probably insert the name of any technology that you wanted to bash in that spot and get an equivalent quip.

Part of why the quote is funny is a real kernel of truth. Any time someone learns a new technology, they attempt to apply it to every problem that comes along. Doing so almost always results in an additional problem. (Using the wrong tool for the job.)

I would, however, like to to counter it with a question from a good friend and mentor, Rick Hoselton:

What do you call a programmer with only one problem?

Unemployed.