Iridescent Bivalve Secretions are from New Jersey, Nacre is from MIT

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 better.

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 class, because package is (and here is where you step forward several steps) pretty much just as good and really the same thing if you squint?

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 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 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 Perlmanity.

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 needs:

• 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 CPAN distributions.

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 together.

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 configure 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 of that. JavaScript is Perl 4 awful in writing large projects, but it spins the pork pie hat of every skinny-jeans hipster in the tech world because it's there.

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.