Lest anyone think I hate Perl 5 for any perceived and real flaws mentioned in Perl Drawbacks and the Marketing Gap, I like almost everything in Perl 5. Its annoyances are particularly vexing because they stick out from an otherwise pleasant experience.
(They're less annoying than they might be otherwise because I know how to use the power of the CPAN to ameliorate them.)
Even still, Perl 5 has good and useful features which hurt the Perl marketing effort. They're useful. They're practical. They're pragmatic. They're consistent with Perl's goals and vision. Some of them are designed and implemented as effectively as anyone can imagine. Yet they hurt Perl's image occasionally -- and I believe that's because people don't understand them.
I can think of three such features. In broad terms, they're lack of ceremony, whipuptitude, and DWIMmery.
Lack of Ceremony
Perl enforces little ceremony on how you do what you do. You don't have to write a lot of boilerplate code to begin a Perl 5 program. You don't have to match filename to class or package name. You don't have to break your code into modules or classes or even subroutines.
You don't have to declare variables. You don't have to pass variables to subroutines. You don't have to declare functions. You don't have to match file headers with declarations. You don't have to run a compiler or linker.
You don't even have to write your code in a file.
You don't have to indent your code in one particular way, or even consistently. You can leave off parentheses. You can leave off semicolons in certain cases. (You can add extras as much as you like.)
You don't have to write tests. You don't have to know about types. You don't have to use built-in operators when shelling out to the operating system would do.
In short, Perl lets you add as much or as little ceremony to your programming as you desire.
This is good, in that every programmer and every programmer team may want something a little bit different. (That desire may change for every program as well.)
This sometimes hurts Perl's image because programmers are lazy. Perhaps it's axiomatic that novice Perl code tends toward the natural idioms of the novice's dominant programming language experience. Perl code in the late '80s and early '90s resembled C and awk and shell because of the Unix system administrator heritage of its users.
Perl code in the late '90s resembled inside-out PHP because of the CGI programmer heritage of its second wave of adopters.
Perl code in the 2000s resembles a curious mishmash of the two (even despite the Perl Renaissance) because novices tend to write code in a pastiche of styles stolen from random examples and tweaked until it appears to work.
These examples, as inconsistent and incoherent and unidiomatic as they may be, tend to work well enough because Perl 5 will happily do a lot of extra work to get the right answer. It's happy to speak baby Perl. It's almost always as happy to speak Baby Perl circa 1994 as it is circa 2009.
In other words, the awful old examples of Perl 5 code won't go away and novices will still copy and paste and modify them and get their work done, if ugly and inconsistent and anything but modern.
I can't see that as entirely a bad thing, even if that means we need to work much harder crowding out bad examples with good examples.
Next up, whipuptitude.
