True, the example is simplistic, but that's just to make it fit within reasonable exposition. The author has in the past shown (elsewhere) how his techniques can actually make dramatic differences in more concrete examples (he rose to some Internet fame for building a performant shell that could actually handle larger outputs orders of magnitude better than most available alternatives).

To me the interesting point is the reminder that there is an innate tension between going fast and being "clean" (i.e. maintanable/understandable). And once you are aware of it you can make your decisions in an informed way. Too often this tension is forgotten/ignored/dogmatically put to the back ("performance doesn't matter over cleanliness" and the likes).

Mind you, I'm also of the camp that performance is very secondary to cleanliness in modern enterprises, but I appreciate a reminder of just how much we are sacrificing on this altar.

It was Windows Terminal he wrote something faster than. Windows terminal was doing a whole GPU draw call per character (at 2x standard terminal height, 160x25, it was as many draw calls as a AAA game).

No matter what design choices you argue for there are always ways to be an idiot about the implementation

Which is an excellent argument for why the WT team should have done some benchmarking, identified that they have a really dumb O(M*N) bottleneck in their rendering code, and optimized it.

It is not an excellent argument for why 'clean code' is not a better fit for the other 99% of their codebase.

I'd say that it really depends on what the code needs to do.

For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility.

But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world.

The advocates of "clean code" that Casey mentions will go for extensibility no matter the use.

I find it very interesting to have numbers to weight what you are leaving when you go the extensibility route instead of the non-pessimistic route.

> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use.

Unfortunately this is just some catchy stereotyping that probably doesn't match reality.

I don't know. Before reading Casey, I'd say most, if not all, of my APIs would look like the "clean code" style.

The process was "think about the model, design a class hierarchy that fits with the model, add the operations". Even if I don't think about extensibility, that's how I thought my code.

Why? Because when I think about performance, I used to think about algorithms and I/O optimizations (for example batching).

Now I'll look into this data-oriented programming-thing and see how that applies to my platform (embedded Java) :D

The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.

That's what you get with SOLID. Madness.

I've seen at least one embodiment of the stereotype 3 months ago. It wasn't pretty, I was able to shrink his code by a factor of 5, and make it more flexible in the process. Among other mistakes he had some idea of flexibility, put part of the infrastructure in place, and then utterly failed to use it, such that when it came to test he required a monkey patching framework for C (Ceedling) so he could mock what he almost already mocked in the source code.

That's a fairly rare breed for sure, but the real problem was that nobody called him out. Well I did, but I'm no longer working there. I couldn't.