> The line count determines how much code I have to speed-read at 3 AM because prod is down.
I disagree, it’s purely a count of newline characters per my original point (e.g., a third of the lines are just `}` or `]`).
> My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable
In my experience, it’s pretty easy to understand `if err != nil { return err }` and the like at a glance. Similarly a for loop that maps a `[]T` to a `[]U`.
I also dispute whether a long chain of .map().foldr().etc() is intrinsically more intuitive than a for loop, especially when the code needs to short circuit. Don’t get me wrong, I like using Rust-style iterator combinators in my hobby time, but it’s because they make me feel clever not because they are more readable than Go-style for loops.
TL;DR, I agree that our brains aren’t getting faster and that readability is important, I just don’t think newlines or the lackthereof are the measure of readability.
> it’s purely a count of newline characters per my original point
It's not simply that. Compare in golang:
var res int
if <some condition> {
res = foo()
} else {
res = bar()
}
to what other languages offer like
let res = if <some condition> { foo() } else { bar() };
The golang version is both more verbose, and more error prone.
These things add up. Let alone how it takes dozens of lines of code in golang to implement what essentially is a sequence of map/filter/groupBy. The logic in languages that support the latter immediately stands out, whereas in golang you have to read it line by line to figure out what's going on.
What's ironic is that even with the proposal to add some of those to golang, they're still going to be vastly inferior to the implementations we have in Java/C#/Scala/etc. because they don't compose in golang, and are still going to be very awkward to read.
I definitely like the ternary version, but to my original point I think people make too big a deal about it. With respect to map/filter/groupBy, I rarely find that solutions are clearer when expressed as chains of iterator combinators like these rather than a single for loop, especially when you're dealing with multiple collections and dealing with errors (short-circuiting). I'm writing a lot of Rust lately, and I definitely find myself dealing with this a lot in practice.
I disagree, it’s purely a count of newline characters per my original point (e.g., a third of the lines are just `}` or `]`).
> My issue with boilerplate is that we have lots of tools for generating it but no well-supported way to summarize it back to something human-readable
In my experience, it’s pretty easy to understand `if err != nil { return err }` and the like at a glance. Similarly a for loop that maps a `[]T` to a `[]U`.
I also dispute whether a long chain of .map().foldr().etc() is intrinsically more intuitive than a for loop, especially when the code needs to short circuit. Don’t get me wrong, I like using Rust-style iterator combinators in my hobby time, but it’s because they make me feel clever not because they are more readable than Go-style for loops.
TL;DR, I agree that our brains aren’t getting faster and that readability is important, I just don’t think newlines or the lackthereof are the measure of readability.