If you think people don't like Perl because the Perl 6 project started
almost ten years ago, you haven't been paying attention.
(Think Python has better marketing? Guido announced Python 3000
before Larry announced Perl 6, and it still took the better part of
eight years for the Python developers to produce Python 3, and people are still
upset that Python 3 is a wholesale replacement for Python 2, and there's still
a debate over when—and in some cases, if—major projects using
Python will embrace Python 3 and abandon Python 2. Think about that.)
Look sometime, really look, at the Perl 6 RFCs.
How many of those problems are still real problems in Perl 5?
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!)
Yet if you're going to put yourselves in the shoes of someone outside the
oyster of the Perl community to say "The name of this project I don't like is
bad, and it makes everyone think you're a stinky boo boo head!", then don't
take off those shoes before you look around at the entire Perl ecosystem. Walk
the rest of the mile. Really think about things.
I'm glad Perl 5 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 5'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 5
in 2011, almost ten years after the Perl 6 RFCs identified 361 pain points in
Perl 5, you still have to download an extension because the Perl 5 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 5
core because it might change, and even if the Perl 5 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. I count myself among them, such as
my contributions have been. Modifying Perl 5 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
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 5 has no Larry. That Larry doesn't have to be the Larry, but a sufficient quantity of Perl 5 hackers must respect the new Larry as a suitable Larry.
- At almost every point where the design of Perl 5 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 6 won't change that. Renaming Perl 5 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
The good news is that, even if you hate Perl 6 and hope it fails and cackle
in your supervillain lair that it's taken ten years, you still have hope. All
you have to do to start to fix the problem is address the fact that Perl 5
- 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 5 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 5 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.
Now tell me how renaming "Perl 6" is going to fix the fact that your average
Perl 5 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 twenty.
Tell me how renaming "Perl 6" is going to fix the fact 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 5 itself fits
Tell me that renaming "Perl 6" 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 5, you must first configure a CPAN client. Oh,
you don't have root access? Convince your system administrator to install and
local::lib, but some people prefer
App::perlbrew, and 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 5 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 5 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 5 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 5 is and can be, and I'm excited for the future of Perl 5. I gladly use CPAN. I look forward to Perl 5.16 and 5.18 and 5.20. I have great respect for every contributor to Perl 5 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
Renaming "Perl 6" won't change the fact that the development of Perl 5 as a
language has demonstrated the relentless desire not to lose existing
users instead of the relentless and focused desire to attract new users.
Perl 6 has that focus. (Indeed, how can it not?)
Want to make Perl 5 more appealing to the person who loaned you that pair of shoes? (Start by giving back the shoes.) Let's talk about fixing Perl 5 instead of fixating on how "Perl 6" means we can never fix Perl 5.
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.