You frequently hear talk about how “Perl doesn’t scale” and “Perl is write-only” and there’s a bit of truth to that. You see, many programmers are still writing Perl 3 code. Now that might seem strange because people still talk about seeing Perl 4 code, but Perl 3, released in 1989, renamed in 1991 to Perl 4 to ensure that the first edition of Programming Perl could easily document a particular version. It was a convenience for the users of the language and not really a major upgrade of the language. So basically, Perl 4 code is Perl 3 code.
Perl 5 was released near the end of 1994 and it was a sweeping change to the language, making it a truly useful tool for building large code bases, including object-oriented programming. Unfortunately, many of its features designed for making Perl a scalable language didn’t catch on for a while due, in part, to so many people being used to Perl 3 syntax. Even to this day, I still get email from people asking why their code doesn’t work and I see Perl 3 code. Such code tends to be poorly organized, harder to read and, no surprise, doesn’t scale well and tends to be “write-only”. So stop writing Perl 3/4.
It still surprises me when people say Perl doesn’t scale well and they ignore that some of the highest traffic Web sites in the world use Perl extensively. Have you heard of Amazon,? Have you heard of Slashdot? A prime example, though, is a company most of you have never heard of, though you’ve probably seen the results of their work all the time. This company is Rentrak.
Rentrak does many things and I worked on the team which tells Hollywood how much money their movies are making. They do this by collecting data from over 4,000 theaters across the United States using a huge system written in Perl. Of course, trying to coordinate data from 4,000 theaters is like herding cats. We received data via FTP, email, SOAP services, Web forms, call center work and so on. Massaging the data and presenting it in all the real-time slice-and-dice formats that studio executives need to analyze their sales is equally complicated. Further, different studios have different needs, and when they make requests, they appreciate how quickly and easily Rentrak could accomodate them. It should go without saying that Rentrak did not write Perl 3 code. On top of that, there are only 4 to 6 developers who work on the code at any one time. We found that Perl scales very well, is easy to manage and because it allowed competent developers the ability to develop code much faster than in other languages, it saved a lot of money, too.
So why is there so much bad Perl code out there? Well, a common path to Perl is through system administration, wanting to add dynamic functionality to a Web site or just as a hobby. Not to paint the people who follow those paths with too wide a brush, but many of them don’t have any formal training in computer science. Discussions of separation of concerns, loose coupling or cohesive functions don’t make a lot of sense to some. They find it easy to quickly throw together what they need and that’s fine — it’s an explicit design goal of Perl. However, programming in the large requires greater discipline than programming in the small and their Perl 3 code isn’t a good fit for it.
To compound this problem, if you’re new to Perl, you often don’t know where to turn for resources. Many of the resources turn out to be startlingly bad. For example, consider perl.about.com’s Top 7 Perl CGI Resources. Those should be the “Bottom 7″. Much of the code on those sites is terribly written and only help to contribute to the poor overall impression of Perl. Many Perl programmers never learn about the CPAN, Perlmonks, perl.com, perl.org or many other truly good resources which will help them learn to use the full power of the language.
One great example of the power of Perl is the File::Find::Rule module. Let’s say you want to clean up your hard disk and you decide to look for all ‘avi’ or ‘mov’ files in some directories:
my @files = File::Find::Rule->file() ->name( qr/\.(?:avi|mov)$/ ) ->in( @list_of_directories );
Now that’s a sweet and easy to use interface, but internally, File::Find::Rule leverages much of Perl’s strengths to make this code fairly short and easy to read (hey, Lisp is easy to read once you learn the language). And let’s face it, as a general rule, if the code is well-designed, less code is easier to maintain.
Are you tired of Really::Annoyingly::Long::Class::Name::For::Customer? Make it shorter!
use aliased 'Really::Annoyingly::Long::Class::Name::For::Customer'; my $customer = Customer->new;
Do you prefer prototype-based objects instead of class-based? Class::Prototyped to the rescue.
Most of the tools you need to build most common applications have already been written and are waiting for you on the CPAN. Those tools plus Perl’s rapid development speed means that competent Perl programmers can move their programs into production before C++ or Java programmers have their first compile (note that I cunningly left other dynamic languages such as Ruby out of that list). That’s not to say that those languages don’t have a place. They’re great languages but we have to put aside our prejudices and understand what’s the right tool for the job. Unfortunately, until we can figure out how to convince Perl programmers to stop writing Perl 3 code, we have an undeserved reputation that’s going to be tough to shake.
Side note: I find it ironic that I don’t hear as many ‘write-only’ comments about PHP even though many programmers can’t tell PHP and Perl apart just by looking at the source code.