in reply to Re^2: sort +*, @array
in thread sort +*, @array

This is a useful explanation, thanks.

However, it seems to me one of the issues "P5ers" have with P6 is, that they can never rely on symbols in P6 having the same meaning as in P5. You give the comma operator as one example and I am using it a lot to retrieve the last element of a list.

So the P5ers might be there most of the way but they would not know for certain...

Replies are listed 'Best First'.
Re^4: sort +*, @array
by BrowserUk (Patriarch) on Dec 11, 2013 at 08:09 UTC
    it seems to me one of the issues "P5ers" have with P6 is, that they can never rely on symbols in P6 having the same meaning as in P5.

    I don't have a problem with P6 syntax being different to P5; even where those differences are subtle enough to catch me out a few times. The products of evolution -- when enough beneficial mutations have accumulated -- are always new species. They live along side each other without interbreeding for a while, and, if the mutations are truly beneficial, they eventually out compete their progenitors and take over niches wholesale.

    In the 10 years since I first became aware of the possibility of P6; I've learnt enough of at least a dozen new languages to try them out on a few sufficiently complex problems that I could compare and contrast their benefits and drawbacks for myself. For the most part, different syntaxes don't bother me too much if they aren't too obscure, are reasonably well documented, and aren't too verbose.

    My assessment of the bits of P6 I've seen/picked up are that it would be right up my street; and that the learning curve would definitely be worth the effort for the gains.

    My only real problem(*) with P6 itself is that for most of the things I do, it simply isn't fast enough. I quite frequently will wait many hours or days for a P5 program to complete -- when I know full well that written in C, or D, or C++ or Java, it would perhaps take 1/2 the time or less -- because I know that it would probably take me longer, than the P5 code takes to run, to write the program in those other languages. That's what keeps me using P5 for the majority of my code.

    But to have to wait a month for P6 to do what p5 does in 2 or 3 days is too much; the gains from the new syntax simply aren't enough to justify it.

    (*)The other problem is the hyperbole and broken promises...


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Yeah on the only real problem being speed(*). Larry thinks speed is the #1 impediment to broad interest and many of us agree. Unfortunately we also agree that the core hackers should focus on creating the right design, getting it working, making it work right, speeding it up -- in that order. So Rakudo has sped up a lot this year (I hope to report on that in January), but most realization of known potential optimizations is yet to come (I anticipate a lot more speed up again in 2014). Btw, if anyone reading this enjoys optimizing, it doesn't require C chops, but just Perl (mostly NQP, a small subset of P6).

      (*) Yeah on hyperbole and broken promises. I think I'm generally avoiding them but I grant both that there's been a lot of this over P6's history and that, perhaps because of this history, folk routinely manage to interpret my statements as being hyperbole and/or promises.

        we also agree that the core hackers should focus on creating the right design, getting it working, making it work right, speeding it up -- in that order.

        All I can say is: wrong call. As with pounds and pennies, take care of the microseconds and the seconds will take care of themselves.

        You can't build a fast car if the tyres are restricted to 50 miles an hour, or the bearing to 1000rpm. Nor if you build the infrastructure using Victorian cast-iron (over) engineering.

        Build a small, flexible, fast core and then see what nice-to-have features it will stand. There is no need for full MOP-style introspection -- no program needs it -- and the penalties it imposes are clear to see...

        (I anticipate a lot more speed up again in 2014)

        Based upon what?

        Btw, if anyone reading this enjoys optimizing, it doesn't require C chops, but just Perl (mostly NQP, a small subset of P6).

        This just doesn't ring true. If the C code that implements/underlies NQP is not efficient -- and especially if the design & architecture of the language runtime is such that it cannot be made efficient -- titivating the the code that runs atop it isn't going to yield the kind of gains that are required to bring it into the realms of real-world usability.

        folk routinely manage to interpret my statements as being hyperbole and/or promises.

        Your parenthetical -- carefully worded as it is -- sounds like a promise; or wild speculation; or dumb over enthusiasm.

        Equally, claiming that +* is "a direct equivalent which retains the ST's generality and efficiency and substantially improves on its elegance." is hyperbole. Which does more harm than good.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
A reply falls below the community's threshold of quality. You may see it by logging in.