In my life I've probably written a few hundred thousand lines of Perl. I've modified and debugged roughly the same amount. Over the past few years, though, I don't think I've written more than a smattering of Perl code.
There's no doubt that Perl is the duct tape that holds the Internet together, functioning as everything from tiny glue and data-massaging scripts to full-blown content management systems such as Slashcode (the code that runs Slashdot), the Moveable Type publishing platform, and Bugzilla. Perl's claim to fame has always been that it makes easy things hard, and hard things possible, and it has functioned and thrived in that world since its inception in 1987.
[ Stay up to date on key software development trends in InfoWorld's Developer World newsletter. | Get a lead on the top five scripting languages on the JVM as reported by InfoWorld contributing editor Andrew Binstock. ]
But these days, the only time I fire up vim to write or modify Perl is when dealing with tools like Nagios and VMware that have a well-established Perl plug-in framework. Otherwise, I find I'm choosing different tools to fit the job.
I've been doing quite a bit of Web work recently, developing custom applications, extending existing apps, and constantly dealing with databases. Nearly all of this code is written in PHP or Ruby, even the backline scripts. It used to be that you'd find many PHP-based projects with little bits of Perl strewn around to accomplish tasks like daily maintenance, file permission checks, setup, and whatnot. Now, many projects are 100 percent PHP to reduce complexity.
There's also been a push in some applications to rewrite Perl utilities in Bash to enhance portability between platforms. While Perl exists on just about every platform out there, there are vagaries that can cause issues with differing Perl versions, which then leads to portability problems. This move makes sense, even if it does seem like going back in time to a degree.
