You Used Perl to Write WHAT?!

We all know that when faced with a job to do, we usually tend to reach for the most familiar tool in our belt. And while perl is certainly a versatile tool, it isn’t the right tool for every job.

More on Dynamic Languages & Web Dev

You Used Python to Write WHAT?

You used JavaScript to write What?!

PHP’s Enterprise Strengths and Weaknesses, Take 2

You Used PHP to Write What?!

Beyond Ajax: Software Development, Two Years from Now

Five Compelling Reasons to Use MySQL

Why Ruby on Rails Succeeded

Perl is the granddaddy of the open-source scripting languages, with the 1.0 release seeing the light of day way back in 1987. By comparison, PHP wasn’t released until 1994, and Python didn’t have its 0.9 release until 1991—only the Unix shells themselves have an older pedigree. The O’Reilly “Camel” book (Programming perl) has been a ubiquitous presence on cubicle bookshelves for decades.

Like any language, perl has its strengths and weaknesses. With that in mind, here’s some recommended uses and abuses of the elder statesman of scripting.

The Good

1. Pattern matching: Perl’s greatest claim to fame has always been the tight integration of regular expressions into the base language syntax. For most developers, perl was the first time they ever used a regular expression.

   As a result, perl has always been the go-to language for any task that involves pattern-matching input. A typical use of this capability is to scan an input stream for name/value pairs and split them. Another is parsing log files with a fixed but variable length format. It’s not for nothing that a lot of the popular log file auditing packages are written in perl.

2. In-place editing: Combine regular expressions with the ability to edit files “in place” from the command line, and perl makes a dandy tool for performing a batch modification on a group of files. For example, suppose you have renamed the /home/george directory to /home/curious, and want to update a few hundred scripts in the /usr/lib/yellowhat directory to point at the correct new path. The following one-liner will do just that:

   # perl -i.bak -p -e "s#/home/george#/home/curious#" `find . -print`

   Now, this is a fairly simple example and could have easily been done using a tool such as sed, but the important thing is that you could have used any arbitrarily complex perl program as the filter, and done highly complex manipulations. Imagine an area code getting split and having to replace a single area code with one of two depending on the original exchange in hundreds of files. In perl, it would be a snap.

3. A replacement for shell scripts: One of the worst things about shell scripting—whether in bash, sh or csh—is that the syntax of the scripts themselves is fairly hard to read. By using perl as a scripting language instead of a “traditional” shell, you can use much more C-like syntax without sacrificing functionality.

4. As a database manipulation tool: One of perl’s strengths has always been the strong database interoperability through the DBI and DBD libraries. If you need to create a quick database report, or convert between a database and some other form of data storage, you can very easily whip up a little utility using perl in very short time.

5. As a cross-platform language: Because perl is interpreted, perl scripts don’t need to be recompiled when moved from platform to platform. And because companies like ActiveState have produced strong ports of perl to platforms such as Windows, most perl programs will run without modification even if they do advanced things such as database connectivity, file system modification or network programming.

Not So Good: Beware

Just like there are places where perl is a great fit, there are some uses that just aren’t right. Here are a few potential applications that should make you run screaming into the night.

1. Real-time or high-performance applications: Perl is an interpreted language. In general, interpreted languages are not known to be speed demons. In researching this article, the most glaring example I found of someone who took perl to a place it didn’t want to go was a gentleman who decided to implement a ray-tracing program for 3-D computer graphics in perl. Even he admits it was a perverse thing to do!

   When looking at a potential application, if it seems to be characterized by a lot of tight loops over intensive calculations, you should probably be looking elsewhere.

   Similarly, if the application is dependent on real-time response (especially life-critical or mission-critical response), perl won’t give you those kind of performance assurances, at least out of the box.

2. As a replacement for shell scripts: “But wait!” you scream, “You just told me I should be using perl to replace shell scripts.” And you should—if you do it right. Consider these two sample scripts:

   @files = `ls .`; for $file (@files) {    system("cp $file $file.bak"); }

   versus:

   use File::Copy; opendir(DIR, "."); @files = readdir(DIR); close(DIR); for $file (@files) {    if ($file =~ /.doc$/) {         copy($file, "$file.bak");    } }

   There’s no question that the second version is longer. However, the first version will fork a subshell to do the ls, and then a subshell every time it moves a file. The second version never needs to fork a shell (which is memory- and performance-wasteful). I’ve seen perl scripts that are nothing but a series of system calls to shell commands.

   Sometimes you can’t get around using a system or backtick command in a perl script, but whenever possible, use the native functionality that mimics the shell call you’d otherwise make. This has the additional benefit of making the script portable. The first version of our sample script won’t run on Windows, while the second one works on both Linux and Windows.

3. As a Web scripting language: One of the earliest usages of perl, as the Web evolved, was for CGI programming webpages. As a result, perl has some pretty strong packages for dealing with Web forms. There is also support for embedding perl into HTML in the same way the Java is embedded into JSP pages.

   However, I would argue that more modern Web scripting languages, such as PHP and Ruby on Rails, offer more out-of-the-box Web support and a cleaner integration into the webpage experience. You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code.

4. In an obfuscated fashion: Larry Wall, creator of perl, famously stated, “Perl is designed to give you several ways to do anything.” As a result, some developers have adopted the style of writing their code as compact and “elegantly” as they can. The results can sometimes be programs that look more like dialup line noise than supportable code.

   Remember that the full version of Wall’s quote states, “Perl is designed to give you several ways to do anything, so consider picking the most readable one.” Break up long lines into several statements, store intermediate values rather than passing them down a long chain of functions and use comments and whitespace to make the code clear.

Perl is a language that can offer a lot of powerful functionality over a wide domain of potential applications. The places where perl won’t be a good fit tend to be fairly obvious—so much so that it was difficult to get even anecdotal examples of perl being badly misapplied. A perl developer tends to know instinctively where it can be used appropriately and where it cannot. So as long as you avoid a one-size-fits-all approach to using it, you should fare well with perl.

James Turner has been writing about open-source software and tools for nearly a decade. He is the former senior editor of LinuxWorld Magazine and currently edits O’Reilly’s OnLAMP site. In addition, he has almost 30 years of experience as a software developer.