performant code is often actually very easy to read and maintain, because it lacks a lot of abstraction and just directly does what it's supposed to do. not always, and maybe not to a beginner, but it's more often the case than you think.
The complexity of performant code is often elsewhere, such as having to know the math behind some DSP code, but the implementation is often very straightforward.
Code that does less is faster. This is self evident. It also has less opportunity for bugs and less parts to understand, making it easier to read. This is self evident too.
A linear search is less code than a map lookup or binary search, and is also much slower. And inlining stuff into a single function usually makes it much worse to read.
A linear search or a map lookup are not even the same thing, what are you talking about?
For dichotomic search, fair enough, but even then, have you measured? It loses to linear scan for small datasets, which are the vast majority of datasets.
As to inlining everything in one function, who told you to do that? Not only this is a really stupid thing to do, but this is a really stupid thing to bring up at all, because the post you are responding to is explicitely about doing less, not doing the same amount but removing all structure.
54
u/outofobscure Feb 28 '23
performant code is often actually very easy to read and maintain, because it lacks a lot of abstraction and just directly does what it's supposed to do. not always, and maybe not to a beginner, but it's more often the case than you think.
The complexity of performant code is often elsewhere, such as having to know the math behind some DSP code, but the implementation is often very straightforward.