2 comments

[ 3.7 ms ] story [ 15.0 ms ] thread
It all depends on the goals of the software that is written. It seems the examples shown are from the perspective of readability, and perhaps modularity (in a way that makes the code easy to understand, which goes back to readability). Within certain limits I think readability is highly overrated and large orgs (aka enterprise software) tends to over-engineer in favor of readability.

IMHO, software should prioritize something tangible. Usually it would be performance, but it could also be extensibility or portability. These are often at odds with readability, and what are you really gaining from super readable code, really? Maybe a few minutes? Compare that to the gains of having performant code or an architecture that scales easily, readability should be the first thing to be sacrificed.

> and what are you really gaining from super readable code, really? Maybe a few minutes?

Wat?? Try a few billion dollars. No one wants to work in a high performance unreadable mess of a service. Otherwise, high-level languages wouldn’t be so common. Python community eats all the other communities for breakfast because of how readable it is. Everyone loves it despite the sluggishness.

Same reason the Rust community and ecosystem are tiny compared to Go, even though it’s “SO’s most loved language or whatever that means.” We could just rawdog machine instructions if all that mattered was performance. Readability matters, and it deserves all the attention it gets and then some.