One of the accusations often levelled at Perl is that it looks like line noise. My standard defence against this is to pull out a piece of my code, which tends to be written in a clear, OO-style borrowing heavily from Perl Best Practices, with, god forbid, comments, as a counter example, which does tend to shut people up, usually with some grudging remark about 'yeah, OK, but it doesn't all look like that'.
And sadly, that's true. It doesn't. Even some of my code doesn't - if I throw together a one or two liner to do some sysadmin task, odds are it'll make copious use of $_, m// and temporary hashes with single character names, and look like one of my cats jumped on the keyboard at an inopportune moment.
Why?
Because Perl lends itself to both styles. It is, in truth, the Swiss Army chainsaw of programming languages, capable of emulating sed, awk, grep and a host of Unix command line tools, as well as C++ and Java, a place where the Perl 3-ish language constructs and innumerable clever command line flags meet the Perl 5 OO syntactic sugar that'll evolve into Perl 6 (of which more in a later post).
Some of the problem, at least, lies in its accessibility. It doesn't take much to learn the basics, and I've seen some pretty ghastly things done in the name of Perl by folks who don't know any better. At one of my former jobs, my most common complaint about some of our new hires was that they were great Perl scripters, but very few of them knew the first thing about being Perl programmers. To quote an article I found while researching this blog, there are too many people out there still writing Perl 3, treating the language like awk-with-added-cool.
If you go a-hunting for Perl resources on the net, you'll find a disturbing number of things like guestbook and article management scripts written by well-meaning people, in a very Perl 3-ish style, some of whom may even, if you're lucky, have heard of CGI.pm, but almost certainly haven't come across CPAN. Now, admittedly, you could make the case that a lot of these are targetted at folks who have a hosting account with no support for extra Perl modules. It is, though, a sizeable part of the problem - the whole perception issue of Perl being a grubby little language for doing dirty little jobs dirt cheap in a dark alley.
I put it to you, in fact, that the very title of the Camel book, "Programming Perl", is a lie. It doesn't teach you to program. It teaches you to write better Perl scripts.
