Crossing the Perl Rubicon

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.

This entry was posted in p5p, perl programming and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

3 Comments

  1. Posted February 18, 2013 at 1:21 am | Permalink

    I fully support Matt Trout's Pumpkin Perl proposal as written (whose clarified What/How post I contributed to). I also think it should be implemented now, when the proposal really is just a change to branding and not to code. This gives us future-proofing for anything else we'd want to do, providing clarity in discussion as to what we're talking about, the Perl that we have been using in production for the last 25 years.

  2. Michael Peters
    Posted February 18, 2013 at 2:28 pm | Permalink

    I want to support Matt's idea, I really do. But I think that any rebranding without any significant changes would just be a mess and subject to ridicule; the exact opposite of a good marketting strategy (even if Matt says this isn't about marketting, it could definitely have a negative impact on said marketting).

    I'm starting to think that the only way to get around this is to have a new benevolent dictator step forward with a vision for a new perl5-like language with a new name. Maybe Moe is it. Maybe it's something else (a fork of the current interpreter).

  3. Maxim Yemelyanov
    Posted February 22, 2013 at 9:51 pm | Permalink

    Just $.02.
    There is high probability that "you'll have to throw your first version (after rebranding and some new work) anyway" thing will happen, so there might be a need to rebrand twice, so that "outside" people won't ridicule the first failure after rebranding.
    But by postponing any rebranding until there's a clean plan means we might never rebrand at all.

© 2009-2014 David Golden All Rights Reserved