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

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 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 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 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. 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 Larry.
• 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 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.

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

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

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

(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 fix Perl.

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.