Last night was the monthly London Perl Mongers social meeting. I hadn’t been for far too long, but I went last night and enjoyed myself.
The talk was as varied as it always is, but one conversation in particular got me thinking. We were talking about YAPC Europe and someone asked if I had seen the Future Perl Versioning Panel. I said I had and that I was slightly disappointed with the make-up of the panel. In my opinion having three people on the panel who were all strong advocates for Perl 6 remaining Perl 6 didn’t really lead to much of a discussion.
In the end, though, any discussion on this subject is pretty pointless. Larry’s word is law and he has made it very clear that he wants things to remain the way they are. And, of course, any discussion of what might have happened differently if Perl 6 had been given a different name or any of the other alternatives is all completely hypothetical.
But hypothetical discussions can be fun.
So lets turn the discussion round and look at it from a slightly different angle.
Imagine you’re in an alternative universe. One where Jon Orwant never threw those coffee cups and the Perl 6 project was never announced. But also imagine that Perl 5 development in this universe had proceeded along the same lines as it has in our universe (I know that’s unlikely as a lot of Perl 5 development in the last ten years has come out of people wanting to implement ideas from Perl 6 – but let’s ignore that inconvenient fact).
My question to you, then is this…
In this parallel universe, at which point in the last thirteen years of Perl 5 development should we have changed the major version number to 6?
I have an answer to the question, but I’d like to hear some other opinions before sharing it.
They might have just done it between the Python 3 and the Ruby 2.0.0 release, just so as to not look outdated. So anywhere between 2010 and 2012 maybe.
Hey, it is Friday after all …
I reckon it should have been the point where the current yearly release strategy was rolling, so 5.12?
Since it’s Friday, you should also have asked “what should Perl 6 be renamed to, to get it off the tracks of perl 5?” 🙂
perl++, camelia, nacre (it’s a real mother of (a) perl!)
‘Nacre’? People would hear that as ‘knacker’. I know that Perl has been called a ‘glue language’, but perhaps that is taking it a little too far…
I’d say 5.10 should have been Perl 6, and then subsequent versions would have been 6.NN, I’d say this because in the business environments I’ve had to use it’s been usually 5.8 that’s available, and you get 5.10 if you’re lucky.
As this seemed to be the hot topic at this year’s YAPC::EU, I had already worked out my thoughts on this in some detail, before I saw that talk. It was nice to find that I was perfectly in agreement with Larry. In that video, the section where Larry speaks from 31:10 to 37:40 is spot on.
Basically, a major version change usually indicates a break in compatibility. Although we have a slow deprecation/removal cycle in Perl 5, it hasn’t been used for anything major (until smart match, which is annoying me a lot…). The whole point of continuing development on P5 is that we want to keep the vast existing codebase. So any rename to v6 would have been a purely marketing move, and would have (a) annoyed people who don’t like being fed a line, and (b) worried casual observers who would think their old scripts were now somehow unsupported.
Put differently, I’m not aware of any strong proposal for a would-be P6, which needs to break compatibility. If someone truly had a need and a plan to develop this, would they really be prevented by a version naming issue? The project for a P5 MOP didn’t stall because they lacked a suitable version number.
I suppose in this parallel universe, you could have attempted to implement the new stuff in chunks such that you always kept a single working lead version – and perhaps we’d be on Perl 8 by now. But you’d still have had the problem of extending or rewriting the legacy codebase, and you’d still have a large majority using P5 for compatibility & force of habit.
In that alternate universe we would be all coding in Python or Ruby.
no freedom never dies 🙂
but yes the only valid comment I see is that the panel (I was there) was really on sided. But if you listen andreii (I like him personally ver much, but) was pretty uneducated as we all are with most things. there are so many good things happen now like the p2/p11 thing which reini does, the new mop-redux, signatures finally may land. I just want to remind you that meaningful discussion can only take place if we know of these things and set an ineligible course.
In this parallel universe, where 5.10 might be the Perl 6 many major issues would not be solved like there are (sometimes partially) solved with rakudo, so no thanks I stay here 🙂 unless someones gives me the secret agent mission to bring P6 to that universe, or is jonathan actually from another .. hold on Larry’s main point is like Elvis: “a little less conversation, a little more action”. I mean enduring, hasn’t have to be something big. But if you really wnat to improve things stick the one itch you really found important through the years to come up with something really wise.
Larry did this with Perl 6 and so should we. amen.
I would agree that 5.10 would’ve made a good “perl 6”: the
introduction of “say” is a small but very visible difference
that deserves to be highlighted.
(There’s one perl re-naming proposal that’s fully
Larry-compliant: continue using the present numbering scheme for
internal discussion purposes, but use “perl ” for external
announcements of major releases. This handles the PR problem,
clearly stating “this is this year’s perl (and perl isn’t dead)”,
without denying the possibility that someday a Perl 6 release
might be this year’s perl. It does nothing for the people who
want excuses to break backwards compatibility, but that’s an
urge I’d rather not see catered to anyway.)
My apologies: I was trying to suggest using “perl YEAR” for external announcements.
Off the cuff, I have three thoughts. (1) it would have been 5.10, when feature.pm was introduced to have a convoluted mechanism for avoiding breakage; (2) 5.12 when strict became the default (albeit requiring “use v5.12”) and pluggable keywords were introduced as another kludge to allow innovation without leaving Perl 5 behind — at that point, tools like PPI effectively became useless because the language is now truly unparsable except by perl (3) around 5.14 when there were a lot of Unicode related changes (including regex stringification) and a bunch of new features, some of which (like auto-deref) wound up suboptimal because of the need to preserve backcompatibility with polymorphic keywords like keys/value/each.
But this counterfaction is all sort of beside the point. Whole classes of innovation were probably never attempted in part because of the need to preserve compatibility. We have kludges upon kludges because a clean break is impossible.
5.010