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.