http://www.perlmonks.org?node_id=770646

Today, I am not seeking... but rather sharing a profound pearl of wisdom that I found while diving beneath my comfort zone of Perl. This applies to "system" as well as "software development":
These three tactics are presented in increasing order of “cleverness.” Such cleverness should be used only when necessary, since it requires a corresponding application of cleverness on the part of the maintenance programmer eight weeks later, and such cleverness may not be available.
Higher-Order Perl, bottom of page 211

It is always better to have seen your target for yourself, rather than depend upon someone else's description.

Replies are listed 'Best First'.
Re: "Cleverness" from HOP
by gwadej (Chaplain) on Jun 11, 2009 at 14:39 UTC

    My favorite quote in this vein is from Brian Kernighan:

    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
    G. Wade
[reply]

      Hmm, I always thought that one was Dijkstra. But I guess not... Thanks.

      ---
      $world=~s/war/peace/g

[reply]
      Fallacy. Twice as hard doesn't mean twice as much smartness required. It can mean twice as long.
[reply]

        I think of the quote as more of a cautionary tale than a logical argument.

        From my personal experience, I have learned that those truly clever and amazing pieces of code that I and others have written always seem to take an extraordinary amount of brain-power to understand and debug later.

        I've also found the quote as useful for making entry-level programmers reconsider their latest masterpiece. Thinking about what it will take to debug a complex system can be a useful antidote to an overly complex design.

        G. Wade
[reply]

        But as you remark, it can. And twice as long can also mean you cannot debug it because you'll be fired by the time you're half-way done for being worth half of what you're paid.

[reply]
Re: "Cleverness" from HOP
by Bloodnok (Vicar) on Jun 11, 2009 at 15:52 UTC
    One of my favourite perls (:-)) of wisdom was one of the first things a formal methods lecturer said to us and it still stands today - he said "Software is the only product guaranteed not to be fully working at the point of delivery"

    I also like the quote from Robinson Crusoe that seems so pertinent to software (mis)management these days: "Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we judge rightly of our strength to go thro' with it".

    A user level that continues to overstate my experience :-))
[reply]
Re: "Cleverness" from HOP
by eyepopslikeamosquito (Archbishop) on Jun 11, 2009 at 21:51 UTC

    In On Coding Standards and Code Reviews, I summarized this sentiment in two rules:

    • Correctness, simplicity and clarity come first. Don't be a clever-dick.
    • If you must rely on cleverness, encapsulate and comment it.

    That is, I don't think you should ban cleverness, just discipline, comment and encapsulate it, so that your code base can be successfully maintained by a succession of many different programmers, with varying talents, over a period of many years.

[reply]
Re: "Cleverness" from HOP
by bluto (Curate) on Jun 11, 2009 at 16:22 UTC
    ...and such cleverness may not be available.

    All code requires a certain level of smarts from maintenance programmers, and it varies by topic. If you are writing an OS kernel there will be things in there that must be clever, or terribly inefficient. In that case if a maintenance programmer can't cut it, the solution is to get someone that can, not put training wheels on the kernel code.

[reply]
      if a maintenance programmer can't cut it, the solution is to get someone that can

      Amen. "Things should be as simple as possible, and no simpler." - A. Einstein.

      The zeroeth step in writing a module is to make sure that there isn't already a decent one in CPAN. (-- Pod::Simple::Subclassing)
[reply]
Re: "Cleverness" from HOP
by BrowserUk (Patriarch) on Jun 11, 2009 at 15:59 UTC

    So what's the alternative? Should we all write dumb code.

    I cannot think of a single other profession where qualified advocate performing their skills to the least common denominator.

    Can you imagine the state of computer hardware if the chip designers said: we mustn't use fine lines; lots of transitors; high clock-speeds; complicated caching, branch prediction or pipelining because it makes testing harder.

    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]

      The point isn't to always write dumb code, it is to not write clever code just for the sake of clever code. If the clever code provides some significant advantage, use it. (And document what it is doing.) But avoid it if there isn't an actual advantage to be gained. Brute force often works nearly as well, and is easily understandable. When that will do, it is usually the preferable option. (Because it is more likely to work and stay working.)

      Oh, and the KISS principle predates programming by quite a bit: Most engineers will vehemently agree with it as well. (That's a field where unnecessary complexity is likely to fall on your head, literally...)

[reply]

        Simplicity is subjective.

        To someone who is equally familiar with A, B, C, D, E, F, ABCD is less simple than EF.

        To someone who is more familiar with A, B, C, D than with E, F, ABCD is more simple than EF.

        The simplicity of the building blocks is not an indication of the simplicity of the whole.

        As concrete example, compare 

        my @a;
for my $b (@b) {
   push @a, process($b);
}

        [download]
        and 
        my @a = map process($_), @b;

        [download]

        I consider the latter simpler or at least equally simple, but others consider it more clever since they haven't dealt with map or they aren't used to dealing with map.

[reply]
[d/l]
[select]

        Trouble is, one man's "significant advantage" is another's "too clever by half".

        All too often "clever code" is used as a synonym for "code I do not understand", and if you do not understand the code, then you almost certainly cannot perceive its advantages.

        I like simple. A lot. But even agreeing a definition of simple is anything but. For many, 'simple code' means step-wise and verbose--the explicit detailing of all intermediates--missing that concise & implicit code can simplify through the omission of extraneous intermediaries.

        to not write clever code just for the sake of clever code.

        "for the sake of", is there a more emotive, subjective, allusory phrase in our lexicons?

        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]
      Howdy!

      That misstates the premise and then follows up with a faulty reducto ad absurdum.

      The common thread there is discerning when it is appropriate to apply high cleverness versus keeping it simple. The return on pushing chip designs is likely to be much higher, as are incremental improvements at core levels. On the other hand, if you don't need the performance gains from pushing the envelope, you can get satisfactory results at a much lower cost. That works for hardware and software. It's not black and white.

      So, it's not a case of "what's the alternative?" That presupposes a binary matter which the proposed answer builds on.

      The HOP quite is speaking to three approaches to a problem with increasing levels of cleverness. Having not looked at the specific example, I can't say for certain, but I'd suppose that the approaches make tradeoffs in maintainability versus performance (for various values of performance).

      Avoiding gratuitous cleverness is not the same thing as writing "dumb" code. Not even close. Completely wrong much of the time, even.

      yours,
      Michael
[reply]
      I cannot think of a single other profession where qualified advocate performing their skills to the least common denominator.

      Politics? ;)

      Although it could be easily argued that the profession does not attract the qualified to begin with since they're smart enough not to go in it in the first place.

      To disagree, one doesn't have to be disagreeable - Barry Goldwater

[reply]
[reply]
Re: "Cleverness" from HOP
by perrin (Chancellor) on Jun 11, 2009 at 18:06 UTC
    The use of the word cleverness here is problematic. It can be very clever to use a good algorithm but write simple and clear code.
[reply]
Re: "Cleverness" from HOP
by wol (Hermit) on Jun 12, 2009 at 13:03 UTC
    • Easy to write
    • Easy to maintain
    • Clever

    Pick two.

    --
    use JAPH;
    print JAPH::asString();

[reply]
Re: "Cleverness" from HOP
by repellent (Priest) on Jun 11, 2009 at 18:51 UTC
    Writing "clever" code and boiling it down a notch to a (subjectively) simple degree should be a healthy tug-of-war, both in the programmer's mind and in interactions with colleagues who have to maintain the code.

    One approach does not fit all situations, especially when we have to juggle between meeting demanding project specs and playing in the team.
[reply]
Re: "Cleverness" from HOP
by whakka (Hermit) on Jun 11, 2009 at 23:43 UTC
    Am I naive in thinking you can write clever code so long as your commenting for it increases exponentially with respect to "unit" increases in cleverness? It seems to be the main reason Perl and other languages with delimiters let you write one line of code on any number of lines you choose. It's the reason for the /x flag on regular expressions, which certainly hold a fair amount of potential abuse of cleverness.

    Also, "cleverness" should really be disambiguated from "obfuscation," which is a deliberate attempt to conceal the intent of code. As a simple example, $|++ isn't clever.

[reply]
[d/l]
[select]
      Am I naive in thinking you can write clever code so long as your commenting for it increases exponentially with respect to "unit" increases in cleverness?

      Yes; comments are far too often a maintenance burden.

      I want the intent of my code to be clear on reading the code itself. Where it's not, I try to rephrase the code for clarity. Where that's not possible, I use a comment to explain the motivation.

[reply]

        Agreed. Comments should explain the why. The what should be blindingly obvious from the code.

        ---
        $world=~s/war/peace/g

[reply]

      I have a recent personal experience of this.

      Half a year ago, I did some intricate mangling of a query language. The delivery schedule was really, really tight.

      People reading my code, complained that all the comments made it hard to read. That was a first. :-)

      With less time pressure I would generally refactor code this complex, so it wouldn't need all the explanations. (Not so "clever" -- more "dense". Just an OO interface to the code's internal data structures would have helped a lot with clarity.)

      The code more or less followed Perl Best Practices, but was still an example on how not to do it... :-(

      Edit: Refactored this comment a bit, so it is possible to parse. :-)

[reply]
Re: "Cleverness" from HOP
by stevemayes (Scribe) on Jul 02, 2009 at 11:47 UTC

    Having read the comments I've got to say that I feel a lot of people are equating 'clever' with 'complex'.

    To write something that is clear, maintainable and does something difficult efficiently is, by my definition, damned clever!

    I am new to Perl but I am not new to writing, and this is a truth I feel carries over from writing.

[reply]

      It's possible that the reason for this definition of cleverness has to do with the amount of 'overly complex' code written by programmers impressed with their own 'cleverness'.

      With that in mind, I would suggest that the code you defined as clever is actually good code.

      G. Wade
[reply]

Back to Meditations