Perl's in kind of a bad way, mindshare wise, but look sometime, really look,
at the Perl 6 RFCs.
How many of those problems are still real problems?
Forget the CPAN. It's not that the CPAN is bad. (It's great!) It's not that you can't find great code on the CPAN to solve many of those problems. (You can!)
I'm glad Perl borrowed and implemented Python's lousy object system in
such a minimal way only in so far as it allows for things like Moose which
replace and improve upon and supersede it in such a dramatic way that I'm not
sure Moose would have existed if Perl's default object system were
Are you still wearing your "I'm not a Perl programmer!" shoes? Step back one more step.
Does it make sense to you that if you want to write object oriented Perl in
2011, almost ten years after the P6 RFCs identified 361 pain points in Perl,
you still have to download an extension because the Perl community can't or
won't agree on one good way to write classes and objects by default and doesn't
want to manage the task of adding an object system to the Perl core because it
might change, and even if the Perl porters took on that burden, you still
probably wouldn't be able to declare a class with the keyword
package is (and here is where you step
forward several steps) pretty much just as good and really the same thing if
Does that make sense to you?
By no means do I fault the implementors. Modifying Perl is
difficult. I don't blame anyone for not wanting to dive into its guts
to refactor things to make it easier to add new features or to fix bugs or to
improve performance or even to see if something is vestigial code which can go
away without breaking backwards compatibility. It's not fun, and people like
Nick and Rafael and Dave and Zefram and Florian and Karl and too many other
people to mention who've done far more than I have have my full respect and
deserve your respect as well.
Even so, take another step in those "I don't know much about Perl, so tell
me about it?" shoes.
Renaming Perl 6 won't change two facts.
- Perl has no Larry. That Larry doesn't have to be the Larry, but a
sufficient quantity of Perl hackers must respect the new Larry as a suitable
- At almost every point where the design of Perl requires a hard choice
between improving (or maintaining the status quo of) the language for people
who've been using Perl for years or decades or improving the language for
people who haven't, the default choice has been to circle the wagons and keep
the status quo.
Renaming Perl won't change that. All of your marketing material can
rigorously refer to "hydrogen" as "Elevo Aeris", but you haven't changed the
physical properties of a single atom. Oh, the Perlmanity. If you believe that
Perl's popularity depends on a feature set, you need somehow to provide:
- A better object system
- Function signatures
- A better reference syntax
- Continued internals overhaul to improve Unicode handling
- Better defaults
- An extension system which doesn't require learning a new language which is half-C, half Perl macros, and half reformed Cimmerian
- A distribution mechanism that solves the Enterprise in Mothballs problem
- A gradual typing system
- A parser reusable outside of the act of writing code
- The possibility of running on other VMs
- The possibility of JIT or other optimizations
- A parallelism and concurrency solution better than heavyweight ithreads
- Improved uniformity of syntax and semantics along the lines of autobox
- An exception system which does the right thing by default
... and I've probably left out a few things.
You can work around many of these problems with the CPAN (in one shot with
things like Task::Kensho and perl5i. Thank Larry and
countless volunteers for that...
... but are you still wearing your "I've heard about this Perl thing, but
why would I use it?" shoes? Take a Perl project of modest complexity. I have
a few with several thousand lines of code apiece. They're not huge projects,
but I've done the rodeo circuit enough times that I get a lot of use out of
Install all of the dependencies of one of these projects in a fresh Perl
sometime. Track all of them. Run Devel::TraceUse on
the top-level program sometime. Go through that list. Group those dependencies
into categories of similar behavior. Go ahead. I'll wait.
The problem is that your average Perl project of moderate size which uses
the CPAN needs to load multiple, competing modules to provide behavior that
arguably should have been core language behavior five years ago, if not ten or
The problem is also that the voluminous documentation to which IRC
continually points frustrated novices (telling them that the F is for Friendly)
assumes in many places a working knowledge of C, shell, and Unix, as well as an
existing overview of how Perl itself fits together.
What will help the frustrated novice who sees a dozen competing projects for
exception handling and doesn't know where to start. Yes, yes, I know,
Task::Kensho, but do you really want to say "To throw an exception in
Perl, you must first configure a CPAN client. Oh, you don't have root access?
Convince your system administrator to install and configure
local::lib, but some people prefer
I hope you're not on Windows, ha ha... wait, where are you going? All you have
to do is pipe a shell program downloaded from a web page into...."
I know, I know. It's frustrating to think that Perl is in a holding
pattern and can't evolve while Perl 6 has been just around the corner for a
decade. But that doesn't change anything. Perl will not evolve into something
more popular for new projects as long as it huddles within the safe,
comfortable fortress walls of "Well, we've always done it this way, and it
would be scary to change it."
(I don't believe that most contributors have that opinion, but given the
difficulty of making changes to Perl and the potential disaster if
part of that change is wrong and the implication that the world could be stuck
with something awful for years if things go wrong, there's very strong
pressure not to do anything. I also believe that the last eighteen months in
the world of p5p demonstrate potential for huge, enormous, world-changing
improvements in what Perl is and can be, and I'm excited for the future of
Perl. I gladly use CPAN. I look forward to Perl.16 and 5.18 and 5.20. I have
great respect for every contributor to Perl and the CPAN and don't
blame any of them for the current situation. It just happened. Good
things are happening. The tides are turning. This is no accident. Now
how do keep that momentum and direct it effectively?)
Features, of course, are only part of the problem. PHP is a mess of a
language in many ways, but it's popular because it does a couple of things
right enough. Ruby is a flawed language, but it has buzz because Rails did a
couple of things right. Python and Perl share many of the same flaws (and
Python adds a couple and takes away a couple), but its marketing message
(however nonsensical) is at least consistent. Lua is incredibly minimal in
features and frustrating in what it lacks, but its designers have a laser-like
focus on what the language is and will be, and it succeeds in its niche because
pork pie hat of every skinny-jeans hipster in the tech world because it's
It's easy to blame "Perl 6" for Perl's conservatism, but it's wrong. Perl
has consistently demonstrated the relentless desire not to lose
existing users instead of the relentless and focused desire to attract new
(Don't hold it against Perl, however. P6 has demonstrated a different
problem: the relentless and focused desire not to produce working
software which might possibly attract users. You can tell because of the
monthly whining noise which comes from Rakudo marketdroids begging for
attention to justify their hobby.)
Want to make Perl more appealing to the person who loaned you that pair of
shoes? (Start by giving back the shoes.) Let's talk about fixing Perl
instead of fixating on how not having a major version number means we can never
By all means complain about the overloading of the name "Perl" to mean two
similar things which are not the same thing. It's an easy target. Just don't
delude yourself that a name change will happen or that it will accomplish
anything meaningful. The version number 6 has been doing its damage since about 2001, and it's hard to imagine that it can do any more.