Re^2: sort +*, @array

I agree with the sentiment that clarity, in most scenarios, is far more important than brevity. But you surely aren't suggesting that code should be so obvious that even someone who doesn't know a given language or dialect automatically knows exactly what code in that language or dialect means?

That said, P5ers ought to be most of the way there:

The sort is a (builtin) function call.
The prefix + coerces to numeric.
The * is a Whatever. (A P6 innovation, explained below.)
The , is the comma operator. (P6 has cleaned up the P5 warts. The comma operator never returns the last value; even in item context it returns a list, as most people would expect.)
@array is an array variable.

All of this is absolutely obvious to even a beginner P6er.

Many P5ers won't know what a Whatever is, and won't know the way the sort builtin interprets closure arguments, so I'll explain those:

The Whatever is as pervasive and basic in P6 as the $_ ("it") variable is in both Perls. In many scenarios, such as this one, a single Whatever means { $_ }. Add in the prefix plus and you have sort { +$_ }, @array.
The sort builtin interprets a single arg closure as its first arg as a "key extractor", which is the clean P6 abstraction of what the map at the start of a P5 ST is comparatively crudely abstracting.

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

Comment on Re^2: sort +*, @array Select or Download Code

Replies are listed 'Best First'.
Re^3: sort +*, @array by hdb (Monsignor) on Dec 11, 2013 at 07:11 UTC
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...	[reply]
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.	[reply]
Re^5: sort +*, @array by raiph (Deacon) on Dec 11, 2013 at 19:57 UTC
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. »ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}	[reply]
Re^6: sort +*, @array by BrowserUk (Patriarch) on Dec 11, 2013 at 20:34 UTC
Re^7: sort +*, @array by raiph (Deacon) on Dec 13, 2013 at 00:31 UTC
Some notes below your chosen depth have not been shown here
A reply falls below the community's threshold of quality. You may see it by logging in.