|
in reply to "Cleverness" from HOP
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.
|
Re^2: "Cleverness" from HOP
by DStaal (Chaplain) on Jun 11, 2009 at 16:53 UTC
|
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);
}
and
my @a = map process($_), @b;
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] |
|
|
Im with you on this for sure. All too often programmers with a poor understanding of Perl label idiomatic and efficient, and elegant Perl structures with "cleverness", when in fact what they are really saying "you wrote something im too lazy to understand so it must be bad". And actually the first code is not the same as the second in various subtle ways, starting with the fact that it performs many more opcodes that the one following, and thus is not going to be as fast (perl bugs aside).
Bad cleverness is writing a cache system for something that doesnt need to be cached, or using some funky algorithm when a plain array would do. Its not about using the language expressively.
---
$world=~s/war/peace/g
| [reply] |
|
|
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] |
|
|
Don't mind me, just a caffeinated ramble.
I think there's simple, there's efficient and there's idiomatic. Simple code is readable by nearly anyone with a general grasp on programming. Efficient does the task with the most efficient use of whatever resources are important to that task. Idiomatic code takes advantage of language features to clearly express an idea more succinctly. Idiomatic code is probably less readable to an unexperienced Perl dev, but perhaps more readable for the enlightened. Because performance is rarely an issue for the code I write, I usually shoot for simple and/or idiomatic and shuffle the code that must be unclear for the sake of efficiency into the dark corner of some library.
My guideline is that clever code is none of the above. Okay, really good clever code may be efficient, but it usually isn't. Most of the clever code I've come across is little more than exploring language features. "Did you know you can do X in Perl?" That's great at home, but I restrict my production code to the idioms I'm most familiar with. Yes, my old production code was simplistic to the point of irritation. Yes, some of my new production code would make a Perl novice twitch while still having simplistic spots that might irritate a guru. But I'm fairly confident that today I could go back and fix a bug in any of my production code. The coders who produced that "clever" code I hate probably couldn't. They've moved on to other features or other languages and probably couldn't even remember why that class needed operator overloading which was so sensitive to calling context or why they had to write the half the logic in an evaluated regular expression.
There's nothing wrong with being clever. It's fun and you learn from it. But I think we use "clever" as a pejorative when it looks like the original dev was just going "look what I can do!"
| [reply] |
Re^2: "Cleverness" from HOP
by herveus (Prior) on Jun 11, 2009 at 20:48 UTC
|
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.
| [reply] |
Re^2: "Cleverness" from HOP
by Popcorn Dave (Abbot) on Jun 12, 2009 at 03:30 UTC
|
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] |
|
|
