[a_imho]

Perhaps even more relevant nowadays

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...

[sanderjd]

I'm not sure if it's due to having come across this quote long ago, but this idea is ingrained in my bones.

Except I think people have often overly focused on "lines of code" as the unit for this metric, leading many to overrate terse code, even when it is very dense.

But I'm not sure what wording would capture this idea succinctly enough to include it in a pithy quote.

[idontwantthis]

Every program should be as simple as possible, but no simpler.

[nordsieck]

There's a benefit to terseness. Go's naming conventions are superior to Java's.

APL (and it's many cousins) is a bridge too far for me, but I can see the appeal to having the entire program on a single screen.

[sanderjd]

Agree to (not entirely, but largely) disagree!

It's funny that you used Go as an example. Like 60% of its raison d'être is noticing that more lines of code is often better if each line is simple. And I think it's mostly right about that. Its inscrutable naming conventions are, on the other hand, a poor choice. (Notwithstanding that java's are a poor choice in the opposite direction.)

[hoosieree]

Dijkstra on APL: https://www.jsoftware.com/papers/Dijkstra_Letter.htm

In one short letter he makes an insightful critique yet misses the the point so hard I can practically hear the woosh 42 years later.