in reply to sort +*, @array

“Brevity” is not necessarily a virtue.   The comment above, “what does this piece of code actually do...?” is actually very telling, IMHO.

#define SOAPBOX

Sure, “clever” is entertaining, as “golf” is entertaining, but I frankly hate to see code that does things such as stringing-together map and grep calls.   Congratulating themselves for “cleverly” do what a nearly-equally short but easily maintainable and clear “conventional” (how boring ...) subroutine could have done just as well.   I hate these things when, and because, I have to change them for some reason.   Then ... well ... have you ever taken apart a Rubik’s Cube?

(To clarify the engineering reason for my beef here ...)   A source-code change that is made to a “compact, elegant, clever” piece of source-code, is of necessity a highly pervasive one, affecting much more than “the minimum change necessary to implement this particular feature or to correct this particular problem.”   Because the whole thing is a Gordian Knot, the change forces itself not only upon the particular issue being addressed, but also every-other piece of logic that runs through this area ... because, likely as not (knot?), the whole thing must be torn-apart and rewritten.   From an engineering point-of-view, this is a serious loss of maintainability – and for no good reason.   Hence, a thing to be avoided, whenever possible, even at the cost of a few microseconds, because human time is really what costs money ... and, business risk.   Please give me code that “obviously” does what it’s supposed to (or that equally “obviously” doesn’t).   And, give me code that I can very easily and “obviously” change, even after its author is long gone, using one very small, very targeted suture.   Don’t oblige me to rig up a heart-lung machine.

Give me clear, every time.   Nothing else.   If it “runs too slow,” I’ll spend $10,000 USD on a mother-of-god CPU to run it with, and it will cost me much less money to do that, than it would to tear-apart and build-up-again “clever” source code written by some long-gone someone who is nowhere to be found (or dead).   Please design your code, not for the “efficiencies” of the moment, but for maintainability aimed squarely at the many decades to come.

#undef SOAPBOX

Replies are listed 'Best First'.
Re^2: sort +*, @array
by raiph (Deacon) on Dec 10, 2013 at 23:03 UTC
    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?" )

[reply]
[d/l]
[select]

      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]
        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]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations