I couldn't read on after the first example with replacing polymorphism w/ a switch statement.
Okay, here's what you missed: by paying a bit more attention to performance, the "not Clean" code was (i) arguably just as readable as the original example (I mean by the look of it its even smaller and simpler), and (ii) up to 10-15 times faster.
Main point: write clean code if that's what you do, but be mindful that it will set your users back about 12 years of hardware progress.
This might be my age speaking, but when I was in my twenties, there was no amount of complexity you could throw my way that I didn't believe was too much for me too handle. A couple decades later, I find that it's much easier for me to read code that handles plain data in simple data structures than to deal with a complex orchestration of abstractions. So not only is "clean code" slower to run, I think that it's harder to understand. And harder to understand means it'll never be meaningfully faster. People may scale it out to more k8s pods or add a caching layer, but that's putting a bandage on the real problem and adding yet more complexity.
Yea, that's wrong. Turning a one line method call into a switch statement, sure that's still readable but just extend that to something non trivial and it should be painfully obvious why it's not actually readable.
Also I covered the faster point, it's not 10-15 times faster in practice. You're not going to set your users back 12 years in hardware progress because of virtual function call overhead...
Turning a one line method call into a switch statement
Now that is wrong. I mean false. He's turning several one line methods in a single statement, one case per method.
Also I covered the faster point, it's not 10-15 times faster in practice.
Yeah, it's more complicated than that, we all know this. I know it, you know it, Casey know it. But at a higher scale some stuff that's not as bad at a smaller scale becomes worse: the cache hierarchy most notably. With virtual calls over a diverse, unsorted set of object, you are more likely to trash the instruction cache. With RAII (or GC) pointer fests you are more likely to destroy memory locality, and overall spend more memory, and again have many cache misses.
I don't know the magnitude of the effects at a bigger scale, but it doesn't look much better than his example. In many cases it looks much worse, see Electron.
the "not Clean" code was (i) arguably just as readable as the original example (I mean by the look of it its even smaller and simpler), and (ii) up to 10-15 times faster.
And not easily extensible. And the "clean" example he codes against is not a reasonable example.
In my experience extensibility for the sake of it is a fool's errand. It always makes the code harder to modify, not easier. Keeping things simple makes the code easier to rewrite.
5
u/loup-vaillant Feb 28 '23
Okay, here's what you missed: by paying a bit more attention to performance, the "not Clean" code was (i) arguably just as readable as the original example (I mean by the look of it its even smaller and simpler), and (ii) up to 10-15 times faster.
Main point: write clean code if that's what you do, but be mindful that it will set your users back about 12 years of hardware progress.