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.
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 either Perl 5 or Perl 6 or changing the version number of Perl 5 to solve Perl's marketing problem will not work.
(Long rant about Perl 6 deleted, except to say that I refuse to take any Perl 6 implementation seriously until it can attract—and maintain—substantive projects written in the language that aren't the implementation itself. Toy programs on Rosetta Code, microbenchmarks, and annual programming puzzles that get broken within a few months don't count. Goodness knows it's more fun to write a compiler or to port a half-finished project halfway to a new virtual machine than to deal with bugs and failing tests or write documentation or figure out installation paths, but 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 5's Real Problems
Perl 5 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 5.)
- 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.
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.
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, daaaaaaaang 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, daaaaaaaaang 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 daaaaaaaaaang if I can't solve a lot of problems with not much code. (Okay, 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.)
Posting grand pronouncements about what Perl 5 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
- Contributing adult supervision to one or another Perl 6 implementation such that it's eventually usable by regular people
- Helping clean up the core of Perl 5 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, the precise relationship of Perl 5 to Perl 6 to the increasing number of programming languages and programmers to program them and projects which require programmers of all sorts and how that has little bearing on the efficacy or popularity of a language (see also the note on economics you skipped over earlier)
- Laugh in the face of employers who refuse to pay more than $20/hour for programmers
Handwringing over what should have been or might have been doesn't do much. (If it makes you feel better, that's something, but don't confuse it for practical action.)