Oh boy, the version number debate has popped up again. The only sensible words on this subject come from RJBS:
... and from Dave Rolsky:
[It's] hard not to be frustrated when it feels like people with a significant interest in the future of Perl 5-like languages are told that all future version numbers belong to a project that has significantly fewer users, developers, and mindshare than the existing Perl 5 language (and community).
... and from John Napiorkowski:
When I talk to recruiters and CTOs and Directors, or to venture capitalists and related investors they have heard of Perl. Perl, period. Version 5 to 6 is not particularly relevant. Changing the version number is not going to impact how people outside our community see Perl.
— Who Cares What Version Number Perl Is?
I normally try my best (such as it is) to avoid putting out unnecessary Stop Energy, but in this case my opinion is clear and proud:
Changing the name of Perl or changing Perl's version number to something which isn't 5 to solve Perl's marketing problem will not work.
Rakudo isn't the answer. Every year that Rakudo only produces toy programs on Rosetta Code, microbenchmarks, and annual programming puzzles that get broken within a few months makes Rakudo less and less relevant. Sometimes not every part of writing software you want people to use is fun. I certainly didn't spent countless hours fixing segfaults and memory leaks in some of the worst code I'd ever seen because it was the most amusing thing I could think of doing.
Perl's Real Problems
Perl has some real problems:
- Lots of people think you can only write terrible code in it. (I wrote Modern Perl to help counter this perception. Ovid wrote Beginning Perl for the same reason.)
- The internals are hard to hack on. (Getting rid of XS may help, but that's a herculean task. So is reimplementing Perl.)
- The defaults are wrong. (The feature pragma is evolving to be much better about this, which heartens me. I didn't expect it to work out.)
- Some features are missing, and they're difficult to add for both technical and non-technical reasons.
- For all practical purposes, Perl 6 is not worth anyone's time.
Perhaps the most important reasons that no one ever talks about: Perl first made it big with system administrators before Perl 4 in the late '80s and Perl made it big again with web developers and Perl 4/early Perl 5 in the late '90s.
Even though Python and Ruby both came out shortly after that, even though people were already using JavaScript on the server side in the '90s, Perl seems old because it had already hit its peak of popularity and greatest share of total market share before 2000.
If you're not exceedingly confident that you understand every word in that final independent clause in precisely the way I meant it, read it again very carefully. (Spoiler: when you start with 90% of the mindshare of a new market, it's easy for people to think you're falling apart even if you're growing. (If that doesn't make sense to you, take an economics class or two or work it out with a pencil and paper.))
I suspect the solution to that is twofold:
- Get used to a polyglot world. Competitors exist. Some are better in some ways. Some are worse in some ways. (I have trouble with languages which can't get lexical scoping right just as I have trouble with languages which can't get well-tested library ecosystems or first-class functions right.)
- Spend more time building software people can and want to use than worrying about marketing concerns like version numbers.
Nobody used Rails back in 2006 because it had great documentation or a good version number or a coherent language design. They used it because it was a lot easier to build a decent website than most of the other technologies out there.
Note well that this is a beginner concern, the same way that is it easier to slap a few PHP tags in a web page and FTP it to a server rather than mucking about with Unix permissions and /cgi-bin directories.
I feel the same way about Moose and Plack and DBIx::Class and the Perl testing ecosystem and the CPAN and, lately, the relative ease of working Unicode. I'd love to have sane function signatures, of course, and core multidispatch and a core MOP, but I can solve a lot of problems with not much code. (Lightweight parallelism and immutability and laziness too, but at some point Haskell has to be better than Perl for certain problems.)
(One might also examine the timeframe for Python 3 replacing Python 2, especially the dominant sentiment which seems to be "I'll migrate when the projects I depend on migrate." Some people might like to believe that the Python community is composed entirely of humorless grownups of the type who see a larger version number and gravitate toward that, but if bigger numbers aren't obviously better even in the Python world, I think we can discard that notion in the Perl world as well.)
In Summary
Posting grand pronouncements about what Perl has to become or the new name it absolutely must adopt won't do anything. That's irrelevant.
The only relevant tasks I see are doing the hard work of:
- Building cool and useful things with Perl and showing them off
- Helping clean up the core of Perl in some fashion such that it stops holding back future development
- Pointing people away from Dreadful Perl to more modern offerings. (Bonus points if you can drag RHEL kicking and screaming into the 21st century. I'll be over here, not holding my breath.)
- Continuing to make CPAN an amazing ecosystem
- Explain, with patience, good humor, and a relentless focus on measurable facts, that Rakudo is irrelevant to people who want to get things done. It's a toy project unburdened by any desire to ship working software and untroubled by adult supervision. It may someday produce something usable, but no one can predict that so do not rely on it.
- Laugh in the face of employers who refuse to pay more than $20/hour for programmers
That's it. Look, there's no shame in being a polyglot. Goodness knows it's difficult enough to find a decent tech job. If you can't use Perl at work, don't fret. It's just a tool in your toolbox.
