My Perl 6 post was really about Perl 5

By dagolden | Published: March 5, 2013

As I see the comments about my Is Perl 6 pointless, hopeless or just not done? article, I realize that I've somehow misled people into thinking I was posing a conundrum about Perl 6.

I'm not.

In the various debates about the evolution of Perl 5 -- how fast it should evolve, whether it should break back compatibility, whether it should be renamed, whether it should be renumbered, etc. -- I find that I can cluster people based on their opinions of Perl 6.

Because Perl 6 promised so much and (so far) has failed to deliver, I find that Perl 6 opinions are a decent predictor of Perl 5 evolution opinions.

If you think Perl 6 is pointless -- or, more politely, just irrelevant to you -- then you probably strongly favor stability of the Perl 5 we have today.

If you find the potential of a backwards-incompatible step-change from Perl 5 appealing (as Perl 6 promises) but you don't think Perl 6 is going to deliver, then you probably favor either more radical evolution of Perl 5 or the possibility of a name change, version bump or fork to break back compatibility for the sake of progress.

If you find the potential of a backwards-incompatible step-change from Perl 5 appealing (as Perl 6 promises) and think that Perl 6 is relatively close, then you probably think Perl 5 evolution debates are tempests in a teapot and wonder why people aren't more involved in helping Perl 6. Or more practically, you may think that Perl 5 can continue to be a stable rock and people's energy is better spent on Perl 6.

[Update: raiph's comment reminded that me that among those who think Perl 6 is close I do find those who are interested in Perl 5-like forks as a stepping stone for Perl 5 to Perl 6 migration. But I don't generally see Perl 6 proponents arguing for major changes in the existing interpreter.]

How do those characterizations help me?

I've spent enough time in the guts of the Perl source and listed to the opinions of those with even great experience and expertise on it that I'm convinced that significant evolution to the Perl 5 interpreter is nearly impossible without a bigger break in compatibility than people are used to seeing in Perl 5.

If the wonders of Perl 6 aren't enough to convince you that you might someday want to switch to something incompatible with what you have today, then none of the far-less-ambitious ideas for Perl 5 are going to justify breaking anything and there's no point in having a debate with you about it.

The likelihood of Perl 5 evolving significantly will hinge on the balance between these groups.

If the pro-evolution but Perl-6-disillusioned group is larger or louder than the other two groups combined, then Perl 5 may yet make an evolutionary leap or there could even be a chance for a critical mass to build around a sufficiently awesome fork.

Otherwise, Perl 5 is more or less done evolving except in minor compatible ways and renaming it or doing anything else ambitious isn't going to succeed in changing the language, the community or external perceptions. We might get Perl 6 or we might not, but the Perl 5 we have now will be substantially the same a decade from now.

If the latter case is what it looks like we have, then I'm pretty much done advocating or participating in further changes in the core, because I think the barriers are too great. I'd rather spend my volunteer time in other areas where I can have more impact.

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

17 Comments

  1. spacer raiph
    Posted March 5, 2013 at 2:57 am | Permalink

    There's a very important fourth group, one that is pro-evolution for Perl 5 and neutral or positive about Perl 6. I believe this includes all four of the "new Perl 5" initiatives Moe, P11/P2, Perlito, STD_P5 and most if not all sixers. It's worth distinguishing this group because they are taking a cooperative approach toward Perl 6, encouraging syntactic, semantic, and toolchain unification where appropriate.

    • spacer dagolden
      Posted March 5, 2013 at 7:01 am | Permalink

      By saying "most if not all sixers" you've just collapsed your "important fourth group" back into my third group.

      Broadly speaking, the "sixers" are not driving the debate about the evolution of Perl 5 itself. They may or may not be in favor of Perl 5 like forks.

      • spacer raiph
        Posted March 5, 2013 at 5:39 pm | Permalink

        While your comments about your third group are logically watertight, they seem to suggest that those who are pro Perl 6 are not a major part of the debate about the evolution of Perl 5. Something is amiss.

        • spacer dagolden
          Posted March 5, 2013 at 6:04 pm | Permalink

          If by "pro Perl 6" you mean people who are interested in using Perl 6 once it is available and who believe Perl 6 will be completed "soon", then that's correct. I don't see them expressing particularly forceful opinions about the need for the existing Perl 5 interpreter to break or keep backwards compatibility.

          • spacer raiph
            Posted March 5, 2013 at 6:30 pm | Permalink

            I'm mostly interested in folk who are leading projects trying to develop an alternative Perl 5 future (without a necessary connection to Perl 6 though all want to be Perl 6 friendly) -- Ingy (p11), Reini (B, p2, etc.), Stevan (p5mop, moe), Flavio (perlitos) -- and folk involved in Perl 6 who sometimes work on bridging to Perl 5 -- Larry (STD_P5), pmichaud and jnthn (p5mop) -- and folk who are pro Perl 6 and fairly knowledgeable about P5, and are rooting for them to converge rather than diverge, even if not currently directly involved in attempts to bridge them -- Nicholas Clark, Moritz Lens, etc.

  2. spacer Patrick Michaud
    Posted March 5, 2013 at 10:39 am | Permalink

    But I don't generally see Perl 6 proponents arguing for major changes in the existing interpreter.

    FWIW, some of the Perl 6 team (myself included) have certainly put our support behind the idea of building a Perl 5 MOP directly into the core interpreter -- that would probably count as a major change. (Thus jnthn++ and I attended the Moving to Moose Hackathon.) But we also know that we have limited tuits to throw at it, so we tend to not be too forceful about it.

    Pm

  3. spacer Jess Robinson
    Posted March 6, 2013 at 3:19 am | Permalink

    Can you qualify/explain what you mean by "significant evolution" of Perl 5? It seems a lot hinges on what this actually means. Is it the same thing as "breaking backwards compatibility" (do we need that to evolve?). If so it would seem that Perl 6 IS the "significant evolution" of Perl 5, in an extreme way.

    If it isn't, then a number of new features have been added and are being added to Perl 5 over the recent years.

    I also understand that efforts are being made to spin parts of Perl 5 core off into modules, which will eventually move their way out of the core onto CPAN, so that anyone who wants to upgrade their Perl to the latest, but not improve their code, can do so.

    • spacer dagolden
      Posted March 6, 2013 at 5:41 am | Permalink

      I said "significant evolution to the interpreter". We can keep layering new minor features on as long as we have people willing to do the work and the ability to toggle them as features. In that process, we add more special cases and make the interpreter that much harder to maintain.

      But i don't expect significant improvements to things like concurrency, performance, ambiguity resolution, parseability and so on. I don't expect evolutions like type-hinting or making arrays and hashes no longer flatten.

      You may or may not agree if any of those big or small are actually needed or desirable, but I assert that such language changes won't happen with the current interpreter.

      • spacer Aristotle Pagaltzis
        Posted March 6, 2013 at 11:57 pm | Permalink

        If you want them to no longer flatten, you want Perl 6. Or some other new clone. It’s a change with so many nth-order repercussions that if you do it well then the language won’t be Perl 5 nor a CPAN VM any more after you’re done.

        You can try to do it without a deep rethink of the language, of course, and it will likely sort-of work – à la lexical $_.

        • spacer dagolden
          Posted March 7, 2013 at 6:25 am | Permalink

          That's what I mean when I say things like "significant evolution" and "nearly impossible" and "bigger break in compatibility..." in the same sentence. :-)

  4. spacer Carl Johnstone
    Posted March 6, 2013 at 4:10 am | Permalink

    Radical evolution of perl5 may mean that we need to break back-compat, but I would presume that it would never happen in one go. So I can take my perl5 application and update it to make use of language improvements at a pace I'm in control of.

    For example I'm currently working on an application where we're slowly refactoring parts of it to make use of Moose.

    Moving to perl6 - as I currently understand things - is an entirely different matter. Our code won't run as-is, we're probably going to have to make large changes to the entire code-base. That's a bigger sell to the business, as it's time spent changing code with no obvious business benefits - it already works!

    • spacer dagolden
      Posted March 6, 2013 at 5:43 am | Permalink

      Perl 5 breaks backwards compatibility in small ways all the time. But I don't think we will see a change that would -- for example -- break 10% of CPAN.

      Just making hash order randomization actually random -- as promised in the docs -- broke a lot of things and was reasonably controversial for that reason.

  5. spacer Buddy Burden
    Posted March 13, 2013 at 2:53 pm | Permalink

    Let me try to carefully wade through my thinking here.

    # Nearly every day, I have someone tell me that Perl is increasingly irrelevant in today's software economy. Sometimes they're even Perl programmers. When you start hearing such things at your all-Perl-shop $work, and even at your local Perl Mongers meetings, you better start listening.

    # Therefore, I believe that some sort of change, radical to one degree or another, _is_ necessary in order to keep Perl alive. It needs a shaking up, something which will force other (non-Perl) people to re-evaluate the language. And, make no mistake: if we continue to make statements like "but I'm using it every day to get real work done!" from down here underground from the neck up while blithely ignoring everyone else who says "Perl is dead" then we'll all end up like the COBOL grognards of our youth. (And, hey: maybe that's okay. COBOL programmers are ridiculously well-paid these days, so I hear. All seven of them.)

    # So if a radical change is required, is Perl 6 it? From my perspective, it _could_ be. It's not now. I know a lot of people say it's ready, and I'm seeing more and more actual code written on it. But the type of code I'm seeing is the type of code I saw in school: academically interesting, but not practically useful. AFAIC, Perl 6 is not ready for one simple reason: no CPAN. Without CPAN, it ain't Perl, at least not to me. It might be a super-awesome language that I'd love to take for a spin one day when I have nothing else going on, but it's not _Perl_. Perl is what I use when I want to get things done. And for that I need CPAN.

    # Therefore, when you ask if a change to Perl 5 that broke 10% of CPAN would be okay, I say, "yes! but only if it's the *right* 10%." :-D There are certain things (DBI, Plack, Moose, etc) that you either just can't break at all, or alternatively you have to work with those authors to ensure they get fixed tootsweet. As long as I can keep _getting things done_, you can do whatever you want to Perl, for all of me. I will definitely not cry if some of my ten-year-old code falling apart is the price for forward progress.

    But there better be some forward progress soon, or else we're all going to be in trouble. Personally, I'll never leave Perl. But I'd like to hope that in another ten years I'm still working in an all-Perl shop, instead of being that one old guy that works on the creaky old codebase that no one else remembers how to fix. :-(

    • spacer dagolden
      Posted March 13, 2013 at 4:10 pm | Permalink

      Well said!

  6. spacer Eljay
    Posted October 7, 2013 at 2:44 pm | Permalink

    I envision a science fiction story taking place in the year 9,999 AD, at the turn of the year counter to 5 digits, where the main characters talk about whether to stick with Perl 5.13070 or wait a little longer for Perl 6.

  7. spacer Sayth
    Posted October 14, 2013 at 8:41 am | Permalink

    Or you just wish Perl 6 would be done so you could try it and have a valid and based opinion about it would be nice.

    But with a release date of 2030 it should be permanently named Rakudo and Perl 7 should be released being a relatively minor modification to Perl 5 which may brake backward compatibility but edit the small annoyances that have been noted overtime.

    • spacer raiph
      Posted October 14, 2013 at 5:04 pm | Permalink

      > Or you just wish Perl 6 would be done so you could try it and have a valid and based opinion about it would be nice.

      Perl 6 is done enough for some folk, and they've tried it (some $dayjob code). Their opinion about it is presumably valid.

      > Perl 7 should be released being a relatively minor modification to Perl 5

      The Perl community asked Larry Wall (and ultimately dozens of others) to each spend thousands of hours working on a solution to a wide array of what they then perceived as Perl 5's problems.

      Now it's clear to folk like Nicholas Clark (perhaps the world's #1 Perl 5 core hacker) that Perl 6 is well on the way to delivering.

      Can you not see that renaming Perl 5 to something like Perl 7 would be a profoundly confusing and disastrous message to the market as well as being a horrible move from a point of view of loyalty to the large group of P6ers working very hard for a key part of Perl's future?

One Trackback

  • By Is Perl 6 pointless, hopeless or just not done? | David Golden on March 5, 2013 at 12:16 am

    [...] « Alternative to Test::NoWarnings My Perl 6 post was really about Perl 5 » [...]

  • Recent Posts

    • The Annotated Berlin Consensus
    • Faster ordered hashes for Perl
    • Perl QA Hackathon 2015 report
    • How to add 'provides' metadata via Makefile.PL
    • What to do if PAUSE tells you this distribution name can only be used by users with permission for X, which you do not have
    • Thoughts on getting Perl 6 for Christmas
    • Sometimes, it really IS a bug in Perl
    • Moving CPAN RT tickets to Github, now improved
    • Setting up a Perl Development Environment with plenv
    • Flaming people versus flaming code
    • Back on the iron blogging horse
    • The next Test::More might break fragile test modules
    • Perl QA Hackathon 2014 Report
    • Why I finally joined Gittip and why you should, too
    • Why you should use getcwd and not cwd
  • Popular Posts

    • Version numbers should be boring
    • Is Perl 6 pointless, hopeless or just not done?
    • Five Test::More features you might not be using yet
    • How to script git with perl and Git::Wrapper
    • Why HTTP::Tiny?
    • How to build MongoDB with SSL for Linux
    • How I manage new perls with perlbrew
    • Fixing screen brightness on Thinkpad X201 and Ubuntu 10.10
    • Is Javascript the new Perl?
    • Coming soon in Perl: CPAN local::lib bootstrap
  • Categories

    • books
    • chef
    • coding
    • cpan
    • cpan-meta-spec
    • cpan-testers
    • devops
    • dzil
    • fixes
    • git
    • hacks
    • meta
    • metabase
    • nosql
    • p5p
    • parrot
    • perl programming
    • perl6
    • toolchain
    • Uncategorized
  • Archives

    • May 2015
    • April 2015
    • March 2015
    • February 2015
    • January 2015
    • May 2014
    • Marc
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.