Counterfactual Perl 6

Several recent posts (more here and here) discuss whether Perl 6 is an impediment for progress of Perl 5 and debate remedies involving changing the name of one or the other. The problem I have with these debates is that they sideline the realities of the current situation in favor of romanticizing a counterfactual.

The counterfactual is this: "If Perl 6 never existed, then Perl 5 could bump itself to Perl 6 NOW in order to signal a backwards-incompatible break from the past."

If the counterfactual were true, I believe this could happen, even with the limitations of the Perl 5 development process we have today. Perl 6 (as it actually does exist today) is revolutionary design, not evolutionary design, but that doesn't preclude an evolution of Perl 5 that significantly breaks backwards compatibility.

Without recommending any particular change, here are some examples of things that I think could be possible, just to give a sense of what evolutionary (rather than revolutionary) changes could attempt:

  • Replacing eval BLOCK syntax with try BLOCK
  • Removing of Unix-specific user/group functions and similar cruft
  • Eliminating of indirect syntax
  • Replacing method call arrow -> with the shorter (and more widely recognized) dot/period character (and finding a new concatenation operator)
  • Eliminating version objects and v-strings
  • Replacing (frequently misunderstood) function prototypes with function signatures

Those are just ideas off the top of my head, but I hope it's easy to see than any of those break enough existing code as to make them very difficult to envision being added to any future release of Perl 5. However, if the counterfactual were true, then there would always be the option of making a clean break to "Perl 6", ensuring that there is no automatic expectation of backwards compatibility.

Even if the counterfactual were true, making such evolutionary changes would not necessarily be easy. It would require a Pumpking (other than Larry Wall) to play language designer for Perl 5 and to push the Perl core developer community into a rough consensus. But hard does not mean impossible.

However, with the reality of Perl 6 as it stands, even a name change by Perl 6 ("Camelia" was one suggestion) doesn't help Perl 5's evolution. Given the expectations that have been set for Perl 5, it seems unlikely to me that there would be broad community support for Perl 5 evolving into Perl 6 if Perl 6 were renamed. "Hi, we promised you Perl 6 ten years ago, but it's not ready for production, so we're going to call this other thing Perl 6 instead." I don't think that's great for external perceptions, either. What then? Jump over Perl 6 straight to Perl 7? I don't think that would be well received, either.

For Perl 5 to evolve in ways that are significantly backwards-incompatible, I see only two realistic options:

  • Rename Perl 5 to something else, with all the associated branding and marketplace traction issues that would cause, but with the ability to make a major version number bump to manage compatibility expectations.
  • Increase the speed of mutation of Perl 5 so that Versions 16, 18, 20, etc. become bigger departures cumulatively than we ever saw with Versions 6, 8, 10, etc., and become much more ruthless about setting future compatibility expectations.

(I suppose an interesting variation on the first way would be for Perl 5 and Perl 6 to be renamed simultaneously. I could see that having some positive opportunities for branding and marketing.)

The status quo alternative is for Perl 5 and Perl 6 to continue as they have been, slowly chugging along on their respective tracks. Perl 5 will continue to put backwards compatibility over evolution and won't see substantial new features added or old mis-features cleaned up. Perl 6 will continue to push towards some sort of production readiness.

For some (perhaps many), the status quo is ideal. For me, I would find it rather boring to be a part of.

So -- let that be the real debate in the Perl 5 community: compatibility or evolution? Names and version numbers are just the means to an end.

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


  1. Posted June 26, 2011 at 11:39 pm | Permalink

    The name "Raptor" doesn't seem to be taken :)

  2. Posted June 27, 2011 at 12:48 am | Permalink

    Drop the 5. Make what would have been Perl 5.16 Perl 16.

    Two more items:

    * make Moose part of core Perl and all core modules
    * drop XS permanently, replace with FFI or ctypes

    • Posted June 27, 2011 at 5:57 am | Permalink

      * drop XS permanently, replace with FFI or ctypes

      Cut the crap. FFIs are useful, but they are in no way a complete replacement for XS and similar approaches. They are convenient, but not powerful enough by a large margin.

  3. Posted June 27, 2011 at 3:37 am | Permalink

    However, with the reality of Perl 6 as it stands, even a name change by Perl 6 (“Camelia” was one suggestion) doesn’t help Perl 5’s evolution.

    I cannot speak for the other participants, but I never made any claim that it would. If you saw that anywhere in my arguments, you misinterpreted me.

    Given the expectations that have been set for Perl 5, it seems unlikely to me that there would be broad community support for Perl 5 evolving into Perl 6 if Perl 6 were renamed.

    Now this, not only didn’t I say that – I’m also as sure as I can be that no one else in the conversation suggested it.

    I come away with the impression that you argue against a position that only you read into the conversation but which no one actually took.

    Names and version numbers are just the means to an end.

    You completely missed the points Brian Meeker made that the conversation centres on. It’s fine if you would rather talk about something else entirely because you don’t care about the current conversation, but the one you’d prefer to have is of no relevance to anything that has been said so far.

    • Posted June 27, 2011 at 7:14 am | Permalink

      It’s fine if you would rather talk about something else entirely because you don’t care about the current conversation, but the one you’d prefer to have is of no relevance to anything that has been said so far.

      I think you've misread my post. My broad point is that the conversation about names (and version numbers) is a distraction from a more fundamental question that people are assuming answers to instead of discussing directly.

      My narrower point is that changing the name of Perl 6 now doesn't undo the damage of the last ten years. I liked Meeker's post a lot. But his Perl 6 observation was about the perception that already exists (and suggesting that widespread Perl 6 adoption might shake things up).

      Thus, given that the perception is already there, what benefit does renaming Perl 6 give to Perl 5? Perl 5 won't become the new Perl 6. It could skip over it to Perl 7, pretending Perl 6 never happened. It could do a major jump in version numbers ("Perl 16"). I think those would create just as much confusion in the market, in part because they would be less advanced that Perl 6 was intended to be. Increasing numbers and decreasing features won't change perceptions of the language except adding a perception of desperation.

      • Christian Walde
        Posted June 27, 2011 at 10:42 am | Permalink

        > Thus, given that the perception is already there, what benefit does renaming Perl 6 give to Perl 5?

        Very very very simple. It allows Perl 5 to start progressing on major version numbers again and shake off the perception of stagnation that it has in the eyes of IT-illiterate decision-makers and money-holders.

        • Posted June 27, 2011 at 10:58 am | Permalink

          That's what I'm saying won't work. Perl 6 already exists in books, web pages and in people's minds. We can't erase that. Releasing something that isn't what the world now knows as "Perl 6" and calling it "Perl 6" would be even more confusing than what we have today.

          • Christian Walde
            Posted June 27, 2011 at 11:12 am | Permalink

            Alright, the existing materials are a good point. I'd not thought of that.

            I still think it'd be a fair cop for Perl 5 to jump to 7 though. That wouldn't be very confusing and while won't address any of the language issues i think it's warranted given how far Perl 5.16 is away from Perl 5.0.

            Plus, most importantly: It would resolve the catatrophe that is marketing Perl to non-programmers.

  4. Posted June 29, 2011 at 1:57 am | Permalink

    About a week ago I talked to my former co-workers about how dead is Perl (the same rant for the last 10 years) and that Perl4, Perl5 and Perl6 are really three different languages, and I realized, that if Perl 5.16 would be released as Perl 6, 90% of developers wouldn't ever notice it's not the real Perl 6. Outside of Perl world, nobody cares that latest version of Perl (at the time of discussion, 5.14.1) was released yesterday, they already know that there's no Perl 6.

    Suddenly releasing a Perl 7 would be a kick in the guts, that's for sure. It's a pity it wouldn't happen.

    • Posted June 29, 2011 at 6:04 am | Permalink

      Reading other blogs on this topic, I get the sense people think this is about external (outside the Perl community) perceptions of Perl 6, whereas I think the more fundamental issue is about internal perceptions. If Perl 5 is a language (and not just an interpreter), how fast should that language evolve and what "versioning" signifies significant change.

      Jesse has laid out an ambitious vision for the evolution of Perl 5 -- a way to have your cake and eat it, too. I hope that it succeeds.

  5. B. Estrade
    Posted October 10, 2011 at 11:03 am | Permalink

    All of your suggested changes are purely surface level and would seriously mess with people's mental model of the language's syntax. I *like* the indirect notation, arrows versus dots, etc. And what's up with replacing s/eval/try/? How is that a value added change?

    Substantial changes to the language, those that happen on the backend, are things like *real* shared memory threading, optional strong typing, and an optimizing backend; it's not sugary changes to the syntax.

    • Posted October 10, 2011 at 5:23 pm | Permalink

      You say it "would serious mess with people's mental model..." and that's exactly what I'm trying to convey. Even "surface" level changes, as you put it, are nearly impossible to achieve given the current set of expectations about backwards compatibility.

      As to the value of the changes themselves, indirect notation is a surprising source of bugs and (IIRC) complicates the parser, which makes other syntax changes more difficult to effect. My RSI would be less severe with dots versus arrows for one of the most commonly used operators and that change would make Perl more familiar/readable to those using other popular languages.

      The try/eval idea would be to separate evaluation (eval) from exception handling (try) rather than overloading both concepts into a single function. eval $string is very different than eval BLOCK. Plus, the exception handling potential of $@ is limited and a new try syntax could more naturally be extended with catch blocks and so on. There are modules on CPAN to do this sort of thing, but they are fairly crude hacks over the underlying eval mechanism and could be done much better directly in the interpreter.

      Whether you or I agree on those is beside the point that they are nigh impossible to actually change at this point in the evolution of Perl 5.

      I agree entirely with your ideas about substantial chagnes to the back-end, though I'm not sure if those are even feasible without a clearer distinction between the specification of the language versus the behavior of the interpreter. Too often, the syntax spec for Perl is "whatever the interpreter currently does".

  6. Posted December 28, 2011 at 3:15 pm | Permalink

    Fork the language, it's the only way Perl will advance. Larry has effectively killed Perl 6 with "urban sprawl", it's been a dozen years and he and the team are still mucking about. Perl does many legacy things in operating systems, but is not the choice for new applications. Perl 5 will die a slow death as the COBOL of scripting languages if action by those outside the Perl development team is not taken.

  7. Posted March 30, 2012 at 5:41 pm | Permalink

    Are you really surprised that people have the logical expectation Perl 6 is the upcoming update to Perl 5? Would you invest a lot of time in version X of a software if the incompatible version x+1 is coming out at christmas? In the fast moving software world, version numbers do make a big difference.

    Perl 6 will turn out great and the people "in the know" understand that the naming thing is just a detail. But most people won't. A decade ago using the next version number for the rewrite of Perl sounded like a great idea. However, after 12 years, it sounds like a misnomer and the reservation for the "next" major version number is not longer valid.

    The Perl 5 community didn't have the luxury to wait for Perl 6 (a good think we took a lot of inspiration from Perl 6 ideas) and continue to make the language great. Let's move to Perl 7. When "Perl 6" is out, I'm sure we'll find a great new name (Perl++?).

    If it's a different language altogether (it is), it should get a new name and not just a version number (that is if you want it to exist in parallel with Perl 5).



    • Posted March 31, 2012 at 1:35 am | Permalink

      I understand the desire for renaming, but I think Larry Wall has been very clear that he doesn't want that to happen. I think the current vision for Perl 5 is to increase the speed of mutation and use explicit version declarations in the code to control backwards compatibility. I hope that approach succeeds.

  8. George
    Posted February 11, 2013 at 9:41 am | Permalink

    Please don't replace "->" with "." ... or at least make both work :-( Same goes for the sigils ... I beat my head against a wall for 5 years to finally learn how they work ... I hope the "new" perl6 approach (invariant sigils) is backwards compatible!! :-)