Isn't Perl Bad?

It's not uncommon to hear a lot of criticism about Perl. In fact it's very common. Among else you can hear:

• Perl code is ugly.
• Perl code is unmaintainable.
• Depending on Perl for a large project guarantees your failure.
• Perl does not scale to high loads or high codebases.
• Perl is slow.
• Perl is dying. (or even that Perl is dead).
• The Perl implementation has a horrible code.
• Perl, or some parts of it (like its Object Orientedness) is very weak.
• Perl is not suitable for writing web applications. (And PHP is).
• Etc.

Some of these complaints are addressed in Simon Cozens' article "Ten Perl Myths" and PerlNet's Perl Myth List. Tim Bunce focused on dispelling three large Perl Myths in a presentation he has given and made available online.

Here are some more observations.

When is Perl the right tool for the job?

We admit Perl has some problems. However, Perl 5 is still possibly the best solution for writing a large class of system administration scripts. And using the Comprehensive Perl Archive Network (CPAN) you can usually get the job done much more quickly and easily than with any other language.

Perl code can be written to be very maintenable, readable and elegant. Perl indeed has many features and behaviors to make writing short programs - often one liners - easier, because one knows this is most of the use people do with it. However, there's nothing in Perl that prevents writing large-scale, maintainenable programs. And in fact such programs have been written and are still successful.

Perl is probably not for everyone. To write in Perl you need good programmers. However, you must always have good programmers, because depending on bad programmers will introduce bugs, security holes, large delays and other factors.