(Note: if you hate the M-word in relation to Perl and the title didn't warn you off, you have only yourself to blame for reading beyond this paragraph.)
Some people hate Perl. Some of them have good reasons. More than you might think don't, but you can't argue with these people. (If they haven't used Perl in 15 years and still hate the language, the only two appropriate responses are ignoring and mocking.)
Some people hate or dislike or don't care for Perl for good--that is, measurable and technical--reasons. Arguing that they should like Perl is a futile activity, but discussing those reasons can be enlightening.
Some people don't care for Perl for aesthetic reasons. I have trouble reading Python code because my eyes slide off over the horizontal whitespace used to delimit blocks. Some people cannot read or disambiguate leading sigils no matter how much they work. Aren't brains interesting?
Like all languages, Perl 5 has its drawbacks. Some of those drawbacks contribute to negative perceptions of Perl.
Note that I'm not suggesting that Perl 5 should or must change nor that any patches or designs are forthcoming or have any chance of acceptance in the Perl 5 core. I merely document opinions I've seen and heard when discussing Perl with people who do and don't like the language.
Perl 5 Drawbacks Contributing to the Marketing Gap
It's easy to write messy code in Perl 5 because the language and compiler does not encourage you to write clean code by default.
In this case, "messy" means "global variables", automagic globals springing into existence upon first use, and action at a distance governed by global variables.
For example, all variables are global by default, unless you declare them as lexical. I know Python and Ruby fans hate the idea of declaring variables (though both languages still have the automagic vivification problem, even if limited to lexicals, not globals), but it solves the scoping problem. Too rarely people wonder if changing the default scope of undeclared variables to lexical from global would have changed the way people wrote code in Perl 1 through 4.
The package global action at a distance problem is obvious when you consider
the
many ways to inherit from a class in Perl 5. Where modifying
@Some::Class::ISA directly can pass for a metaobject system, it's
an ugly metaobject system.
I like Perl::Critic and Perl::Tidy for cleaning up bad code, but preventing people from writing bad code by encouraging them to write good code from the start seems like a better approach.
Similarly, I have only good things to say about Moose -- but it's an additional library that people have to install before they can use it. (Kudos to the first extended Perl distribution which includes Moose and other Task::Kensho modules by default.)
CPAN is indeed the best part of Perl 5, but until CPAN distributions are as easy to install as the average PHP application is to deploy, I believe people will still see CPAN distributions as, at best, second class extensions with no guarantee of working together effectively or correctly.
Backwards compatibility is generally a good thing, but the fact that the Perl 5 parser can (and has to continue to) accept, silently, random garbage written fifteen years ago by someone with no business writing maintainable code isn't necessarily a benefit. Yes, it's good that Perl 5 doesn't wantonly break working code, but when it costs 3% of the Perl 5 parser to support a feature obsoleted by Perl 5 in 1995, and when the replacement feature makes code simpler, more concise, and easier to read, it seems like a credible time to consider the cost of supporting old, obsolete features.
Perl has no Big Name Corporate Sponsor. That can be a good thing--Perl doesn't depend on the whims and fortunes of any single company, but it also relies on the kindness and interests and free time of a collection of individuals for advocacy, development, testing, experimenting, polishing, and support.
Then again, volunteer Perl web sites have lately far surpassed the utility, attractiveness, and freshness of supposedly well-sponsored corporate sites.
I don't even have to write about the abominable book, tutorial, and training material situation. A handful of us scream into that void, but it'll take some time before we can fill in that gap and erase the collective memory of Matt's Script Archive from the Internet.
I know, I know -- mature, experienced Perl programmers know how to work around all of these problems. They're not problems if you've written effective Perl for five years.
Put yourself in the shoes of a novice for a moment. Forget that you know how to configure the CPAN client. Forget that you know the difference between @ISA = 'Parent'; and use base 'Parent'; and use parent 'Parent';. Pretend that no one has told you that Perl 5 can catch your typos for you (if you ask it ) or warn you about deprecated constructs (if you ask it) or recommend alternate approaches that are safer, more secure, more concise, more readable, and better supported (if you install additional software and ask it).
In short, pretend that you want to write good, modern Perl 5 -- not Perl 4 -- and don't know how. How much time will you have to spend fighting the obvious battles before you realize what to do differently?
(Before you start angrily telling me that PHP and Python and Ruby and Haskell and C# and who cares what else have similar problems, I don't care, because I'm not talking about that. Feel free to have that discussion elsewhere.)
Next time: Perl benefits.
