http://qs1969.pair.com?node_id=855743

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

References are one of the things I love about Perl 5, After reading this document I got to know they are no longer there in Perl 6. Won't we be missing such a beautiful thing.

Replies are listed 'Best First'.
Re: Reference in Perl 6
by moritz (Cardinal) on Aug 18, 2010 at 11:44 UTC
    The statement that there are no references in Perl 6 is misleading at best.

    In fact, nearly everything is a referece.

    # $x is a reference my $x = SomeClass.new(); # this also doesn't need an explicit reference my @a = 1, 2, 3; my $arr = @a; # now you can use $arr instead of @a, though $arr won't flatten into l +ists by default $arr.push('foo') say ~$arr; # 1 2 3 foo

    So references aren't gone; just their visibility has decreased drastically, as well as the need for explicit derferencing.

    Also function arguments are passed by read-only reference by default.

    Perl 6 - links to (nearly) everything that is Perl 6.
      So references aren't gone; just their visibility has decreased drastically, as well as the need for explicit derferencing.

      This comment fills me with dread. I understand Perl 5, where a reference is a reference, and if I want the thing it refers to, I manually de-reference. Simple enough. I've got that. (I also understand Python's way of doing things: every variable is always a reference, and the system de-references as necessary and everything just works.) But I don't like the sound of (Perl 6's) "their visibility has been decreased drastically". Are there many special cases where sometimes there's auto de-reffing and sometimes there isn't? What is the uniformity of the design that I don't yet see?

        Why do people always assume the worst, and place no confidence whatsoever in the language design team?

        Of course we've worked hard to make the design as non-uniform and counter intuitive as possible</sarcasm>

        Perl 6 - links to (nearly) everything that is Perl 6.
Re: Reference in Perl 6
by sundialsvc4 (Abbot) on Aug 18, 2010 at 15:36 UTC

    Okay, folks, I’m gonna step out on a limb here.   I am not wishing to start a flame-war, and I beg your forbearance not to permit one to start.   I might be wrong here, but I think I’m right.   (And if not, it is just “IMHO,” and all of us here know how to deal with that.   So, here goes...)

    In effect, Perl-6 becomes an entirely new language, with Perl-5 as its primary competition.   And, I believe that the Perl-6 team will be rather shocked to discover that their baby has no wings and will not fly.

    A similar experience was shared by the various folks who tried at various times to create “ADD 1 TO COBOL GIVING COBOL.”   No matter what they did to try to “improve” the language, all of their “improvements” would have imposed gratuitous non-compatible changes upon tens of millions of lines of installed-and-working source code, with no significant return on investment.

    Every now and then, someone comes along and says, “you really should re-implement all this stuff in (X) ... it will be so much better!”   And the seasoned executive holds up her hand upon hearing the word, “re-implement,” and says: “Stop right there.   No.

    The (X) could be “Perl-6,” or it could be Ruby or any one of a half-dozen other recent silver bullets, or it could be the next silver bullet yet to be invented, but the fallacy is the same.   The project would entail huge business risk, and probably would not provide business benefit, let alone a financial return.

    Trivial example:   Go to your source-code directory and type “grep -rilw eval * | wc -l”.   If someone on the Perl-6 team decided that try was a sexier word to use than eval, and did not have the foresight to allow both words to be used ... then this is the number of source-code files that must be changed.   (And then changed back, if the Perl-6 rollout does not go exactly as planned.)   Meanwhile, where is the profit in it?   There isn’t one.   Huge risk, no profit.   So, what is the appropriate business decision? Stick with what works.   Stick with what is working now.   Let this “silver bullet” remain on the curiosity shelf with all the rest of its very many kin.

    Furthermore, we have Moose.   Now, here is a very intriguing tool that introduces a strong object-oriented flavor to the Perl-5 language, without using an overt preprocessor, and without excluding the continued use of Perl-5 in the same system.   This is the kind of technology change that might get accepted by that same senior executive, because the risk of adoption is much lower and the implementation strategy can be incremental.   Even so, it still might not make the cut, although it is arguably “better.”

      Two things. First, it was stated very clearly from day one that the purpose of Perl 6 was to break backward compatibility in all the ways it needed breaking, so you should not be at all surprised ten years later that we're breaking backward compatibility.

      Second, it is my belief (which may take twenty or thirty years to falsify but could be truified rather faster) that for every manager that does not use Perl 6 because it is not Perl 5, there will (eventually) be N managers who will use Perl 6 because it is not Perl 5, for some N greater than unity. If I didn't believe that, I wouldn't have spent the last decade pouring my heart and soul into it.

      As for whether Perl 5 and Perl 6 are different languages, that's kinda silly; every new version of Perl is a different language. The only question is how different, and the answer to that is never 0% or 100%. On this, as on most issues, I am a flaming moderate, and do not appreciate arguments that ignore one half of the truth or the other. I'd rather see the whole truth.

      And the other half of this truth is that people who have actually programmed in Perl 6 tend to report that it still feels very much like Perl on some fundamental level, regardless of the various syntax and semantic tweaks we've made. So it really depends on the meaning of that fuzzy term "Perl". As a linguist, I'm quite content to let definitions be fuzzy like that. :-)

      I don't think the way to re-use Perl 5 code in Perl 6 will be to just copy it over, and run it with a Perl 6 compiler.

      Rather the Perl 6 compiler and runtime will talk to to the perl 5 compiler/interpreter, and that way you can use Perl 5 modules in Perl 6.

      In that case it doesn't matter if one of the two usages of eval is now spelled try in Perl 6, and there's no reason to change any file - you'll continue to run your Perl 5 scripts with perl 5, and you'll write Perl 6 scripts in Perl 6, and use Perl 5 modules.

      That's not just a glimpse of the future, but it actually works (with limits, but it does work). Tim Bunce demonstrated usage of the Perl 5 DBI in Perl 6 code through blizkost at YAPC::EU 2010.

      Perl 6 - links to (nearly) everything that is Perl 6.

      That's a silly scenario.

      It's much more plausible to believe that any new Perl 6 code which exists will do so out of a desire to write something new in Perl 6 rather than to replace and subsume and erase from existence existing code in Perl 5.

      (Also, misquoting Fred Books annoys me.)

      In effect, Perl-6 becomes an entirely new language, with Perl-5 as its primary competition.

      FWIW, I don't see Perl 5 as Perl 6's primary competitor (although perhaps I'm being quite naive in stating this). I'm not really after all of the people who program in Perl 5 and are happy with it; I'm after the folks who think that Perl 5 is too ugly, complex, or otherwise has too many rough edges such that they instead choose some non-Perl-compatible scripting platform altogether.

      To me, one of the primary goals of Perl 6 is to create a Perl that is more palatable and accessible to the people who won't or can't consider Perl 5 as a choice. That's the audience I'd really like Perl 6 to reach.

      Pm

        primary goals of Perl 6 is to create a Perl that is more palatable and accessible to the people

        Right, You need to CREATE it first to test its real use. How much more time will it take? Another decade? But what you define as a "ugly, complex, or otherwise has too many rough edges" language has managed to survive nearly 17 years of evolution with millions of users and its maker took probably just 3 years to build it. And is still going strong. We'll see how strong Perl 6 holds out against Perl 5 when they are in competition in the real world. But for that to happen first it must come out clean.

      I believe that the Perl-6 team will be rather shocked to discover that their baby has no wings and will not fly.

      What's your point? What would you have the Perl 6 team do with your assessment? Should the Perl 6 team say "Holy shit, he's right, we're going to change try to eval?"

      This is not a rhetorical question. I really do want to know what the point of your assessment is.

      xoxo,
      Andy

        I don’t know how to make an “assessment” here, beyond my original comment, which by the way was not intended to be personal.

        I have, in fact, taken several long, hard looks at Perl-6 now, and my take-away is simply that, once any language comes into a production setting, such that literally millions of lines of mission-critical code are written in it, it never goes away ... and it never successfully transforms itself into something significantly different.   It does not matter if the “successor” is claimed to be much better.   (It does not even matter if it really is.)   What matters is a vast investment in reasonably bug-free source code that must now be protected and maintained.  

        Perl went quickly through many “nothing much” incarnations until ... Perl-5.   Then, it reached critical mass.   Having done so, it will now be with us, as it is, for an exceedingly long time.

        I once worked at a shop that still licensed IBM’s FORTRAN-G compiler ... because they had a large and important system that was written in that dialect.

        The assessment is that everything that relates to Perl 6 is half complete. Implementation, books, modules anything you name. What you get to see always are blog posts describing it as some kind of grand unified language which will take over the world and survive for some two or three decades. When that will happen we will happily embrace it. But until then stop killing Perl 5 at Perl 6's imaginary existence in the probably future.
      And, I believe that the Perl-6 team will be rather shocked to discover that their baby has no wings and will not fly.

      Baby butterflies don't actually have wings.

      In effect, Perl-6 becomes an entirely new language, with Perl-5 as its primary competition.

      Yes, you're right.

      You are welcome to your opinion, but please, go back and do some rudimentary research on the history of Perl 6 and its design before you say things like the Perl-6 team will be rather shocked to discover that their baby has no wings and will not fly.

      BTW: I don't recall anyone claiming it will be a silver bullet.