Yes, this is another blog post reacting to Matt S. Trout’s Pumpkin Perl idea. (His followups are here and here.)
I’ve considered a long, thoughtful reply about what I see as the problems Perl 5 faces, why various proposals I’ve heard fall short, and what I think is meaningful for the future of Perl 5. But I’ll probably never have the time to write that.
Instead, I realized that a recent email exchange with some other Porters summed up my thoughts about Matt’s plan well enough to share. It will have to do.
Here was my original email, more or less, with some added emphasis:
If we go all the way, and rebrand from “Perl 5” to “Pumpkin Perl 1”, then we open the door to a future “Pumpkin Perl 2” that breaks backward compatibility with a major version bump.
I’m neutral on whether it will do anything for internal and external perceptions, but at least it would solve this major version problem we’re currently stuck with. That is not a trivial benefit if we seriously want to evolve Perl in a significant way (whether with this interpreter or a future rewrite). It doesn’t get us out of the box we’re in, but it at least opens the flap.
I’m not sure what such a bump would mean internally with respect to patchlevel.h and PERL_REVISION and PERL_API_REVISION. Possibly those go to 6 and any external version displayed is PERL_REVISION - 4 and we do the version monkey dance like Java did. There are plenty of devils in the details…
Then, in a very thoughtful response, Jan Dubois raised some concerns about what I said about breaking backward compatibility. Here is a short excerpt of his email (reprinted with permission):
If we go all the way, and rebrand from “Perl 5” to “Pumpkin Perl 1”,
then we open the door to a future “Pumpkin Perl 2” that breaks
backward compatibility with a major version bump.
I actively dislike the suggestion above, in case it actually is part
of the plan.
If there ever is a version of Perl that breaks backwards
compatibility, then I sure hope it will use a *different* name, and
not just a bump in version numbers. Not being able to rely on
/usr/bin/perl being a compatible implementation seems like a sure way
to make Perl even less popular…
And here is my response, with slight editing and some emphasis added:
I don’t think there is currently a “plan”. There’s just an idea.
That said, I don’t see much reason to rebrand *unless* there is a plan that is at least conceptually along those lines.
Whether such a binary gets called “pumpkin” or whatever is a bikeshed color issue.
If it’s still recognizably “Perl 5” as we know it – perhaps with a little less of some things and a little more of others – then having a name like “Pumpkin” that carries from 1 to 2 would be very helpful for continuity.
This is *exactly* what Perl 6 prevents currently. We can’t bump to 6. We probably shouldn’t bump to v20 and then have annual releases be v22, v24, etc. or the significance of a major version bump is lost. (“Oops v30 was the one that broke backcompat, didn’t you realize that?”)
**IF we think there will ever be a future Perl 5-like language/interpreter that is a significant departure from what we have today (that isn’t Perl 6), then we really need a way to signify that with some sort of major bump or change in either version or nomenclature.
**
(I realize that’s a huge if. Caps doesn’t do it justice, it’s so huge.)
Some have made very good arguments that there’s no point changing a name *until* we have this hypothetical future Perl 5-like thing ready to release – that until we have something to show that no one will pay attention.
That may well be. On the flip side, we set up a double barrier to change: not only must the actual work be done, but said doers must contemplate (and then wage) the secondary battle over version and nomenclature.
**What Matt proposes – at least in my interpretation of it – is to cross the version/nomenclature Rubicon *now* when there *isn’t* anything at stake. Once that happens, contemplation of more significant change can focus on the design and technical issues, because at the least the first cultural barrier will have been trail-blazed.
**
Again, I’m not wildly agitating *for* this Pumpkin idea – I don’t trivialize the big “if”. But if I ignore 90% of what people think it will or won’t do, I still think it does give this glimmer of a future that to date has seemed impossible and *that* is the part I think is worth discussing.
In summary, if we really are going to have Perl 5 and Perl 6 as sibling languages, with each evolving independently, then we need to decide whether we ever anticipate the possibility of Perl 5 needing to make a major break. If so, then Perl 5 will have to cross the Rubicon eventually.
Do we do it now to pave the way? Or do we do it later when the break appears?
Those two questions – “Will we ever or won’t we?” and “Now or later?” – are the ones that matter.