It does not really apply to software, where most good programmers are obsessive and hard working. Yes, that also applies to Lisp, where someone has to write the actual interpreters and compilers that others use to run their 100 macros on and pontificate how easy everything is.
Conciseness can be a product of prolificness too.
1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplishes the same task and only one person in the company understands...
NASA averages something like 0.1 bugs per 1,000 lines of code, industry average is closer to 15.
Surely there are other factors, like testing, linting, and language choice that influence the number of bugs.
As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
Clarity is far better than terse code that suffers from leaning toothpick syndrome.
I don't know Perl. But I'm prepared to do that exercise for APL if you want.
> As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
Bugs are correlated to line count because code complexity drives line count and bug count.
It’s not the number of lines of code causing the bugs, it’s the complexity of the problem causing the number of lines and number of bugs to grow independently of each other.
Correlation does not imply causation.
Statistically maybe, but when it comes down to it, clear code > compact code hands down.
Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies.
I'm not smart enough to be able to read and understand a nested ternary or other examples of clever / compact code.
Anyone who's seen an enterprise Java codebase knows there's a third way: so verbose that no-one can tell whether there are any deficiencies, even if each line in isolation is "simple".
I think we vastly underestimate the importance of sheer code length. Being able to comprehend the function, class, or program as a whole makes a lot more difference than whether nested ternaries or the like were used, IME.
Poor example. Any Perl programmer can explain both range ops without breaking a sweat. Smart matching is/was the weird, misbehaving thing.
The smart-matching in Raku (formerly known as Perl 6) is asymmetric and customizable. If you write:
a ~~ b
b.ACCEPTS(a)
I have worked with brilliant people who still have trouble figuring out the ternary operator, and people who should know better who construct ternary operators with five levels of parentheses, causing deciphering of the intent to be impossible.
So I choose Alexander the Great’s approach to solving the Gordian Knot: slice it open and remove the complexity to multiple layers that mere mortals can understand.
PS: I notice you failed to explain the operator yourself. Minus five points to Slytherin.
Does it count as a trick question if I implemented it?
Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.
There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be.
It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related.
Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.
Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.