Clear is better than clever [pdf] • Hacker News Board

Re: Clear is better than clever [pdf]

#21

Post by userbinator » Mon, May 06, 2019, 11:42 AM UTC

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear; I think it's best written in a single line:

    return a  b ? 1 : 0;

That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially prevalent recently, since the idea of making a simple thing simple is so enticing and easy, but emphasising "micro-readability" to that extent (that's 10 lines of code for two simple decisions) will bloat the code and make "macro-readability" harder, and it's the latter that really matters for the understanding of complex software.

Anyone who has the experience of reading lots of highly trivial functions like those, and gotten the feeling "I've read a lot of code, and I understand what each little bit does, but what is the whole thing trying to do?" That's a symptom of excessive verbosity.

To offer another (subjective) point, I think the lack of semicolons or other statement delimiters does make code harder to read, as it makes it look similar to a run-on sentence. Natural languages have punctuation for a similar reason --- you can quickly scan over sentences by finding their delimiters.

Also, the counterargument: https://www.linusakesson.net/programming/kernighans-lever/in...

Re: Clear is better than clever [pdf]

#22

Post by eternalban » Mon, May 06, 2019, 11:44 AM UTC

"When declaring and initializing do ...".

Thank you Dave but some of us prefer explicit 'vars' all the time and reserve := for quickie peripheral variables.

Re: Clear is better than clever [pdf]

#23

Post by __s » Mon, May 06, 2019, 11:46 AM UTC

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

Meanwhile I'll write (a>b)-(a<b), which is what Python suggests after having removed cmp

Re: Clear is better than clever [pdf]

#24

Post by zaphar » Mon, May 06, 2019, 11:48 AM UTC

jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

    Focusing on readability of the code and 
    putting "machine execution" second, 
    means putting the user experience 
    second

Nothing kills a users experience like buggy code. Nothing contributes more to buggy code than unreadable or unclear code. This is why another proverb often quoted is "First make it correct, then make it fast". Fast but buggy code will lose to slower but correct code everytime.

Re: Clear is better than clever [pdf]

#25

Post by zeroxfe » Mon, May 06, 2019, 11:53 AM UTC

ahartmetz wrote: post #12

auggierose wrote: post #3

> To be clear, I don’t mean to dismiss the work of a lone programmer toiling on programs without anyone to pair with or learn from. I’ve been that person many times in my career as a programmer, it’s not fun. I'd say it's a lot of fun.

It completely depends on the quality of your collaborators. Are they good developers, do they have somewhat compatible views, and are they reasonably friendly? I prefer working in a highly capable group.

Yeah, working with other good devs is fun too, but working alone is a special kind of fun. :-)

Re: Clear is better than clever [pdf]

#26

Post by Nasrudith » Mon, May 06, 2019, 11:54 AM UTC

jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern.

More charitably, a better argument is that it is easier to adapt a compiler to reoptimize it than to tweak the entire code base - let alone the costs for the gains.

Re: Clear is better than clever [pdf]

#27

Post by derangedHorse » Mon, May 06, 2019, 11:55 AM UTC

eraxley wrote: post #16

arhyth wrote: post #11

just new to Golang (in programming in general, actually) and this bug me. in the slide, it's indicated they are semantically the same. but how? (1) var thing Thing json.Unmarshall(reader, &thing) (2) var thing *Thing = new(Thing) json.Unmarshall(reader, thing) in (1) thing is a variable for a value of type Thing, while in (2) thing is a variable for a Thing pointer shouldn't thing (2) need to be dereferenced first?

You are right that (2) needs to be dereferenced first, however, in go a pointer is autmatically dereferenced when accessing its properties or "methods". What I mean by this is that if you want to access a property on thing, it would look the same. In C++ it would look like this: (1) x = thing.Property; (2) x = thing->Property; (or (*thing).Property) but in go, both would look the same, like this: (1) x = thing.Proper…

That's one of the things that I hate about Go. That and how they force me to write an 'else' on the same line as the closing brace of the 'if'.

Re: Clear is better than clever [pdf]

#28

Post by dullgiulio » Mon, May 06, 2019, 11:56 AM UTC

Nasrudith wrote: post #26

jodrellblank wrote: post #18

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" s…

To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern. More charitably, a better argument is…

We have been waiting for the "sufficiently smart compiler" for around 4 decades now. If it's so easy to write one, where are they?

Re: Clear is better than clever [pdf]

#29

Post by Leszek » Mon, May 06, 2019, 12:04 PM UTC

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

Thank you for mentioning micro- vs macro-readability, I feel that too often people concentrate on the former without considering the latter.

Re: Clear is better than clever [pdf]

#30

Post by Nasrudith » Mon, May 06, 2019, 12:05 PM UTC

dullgiulio wrote: post #28

Nasrudith wrote: post #26

Earlier quoted context omitted.

To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern. More charitably, a better argument is…

We have been waiting for the "sufficiently smart compiler" for around 4 decades now. If it's so easy to write one, where are they?

It is on a spectrum but it is already here to some extent. Look at previous performance practices which have become deprecated like manually unrolling fixed for loops. Those are the sorts of things which have been fixed up and assembly coding is pretty rare still.