“Clean” code, horrible performance

You believe you're right, which of course you do, you almost can't help it.

Still, you keep mentioning Linux and it's worth a moment to consider that Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends and which Casey warns you will have egregiously bad performance. Several whole CPU cycles slower than Casey's spaghetti in fact.

Let's look more closely. In Casey's Clean example the Shape subclasses have to carry a table of functions to call to find out e.g. the area of that Shape, and then as we walk our array of Shapes we use these tables to call the appropriate area function. This costs us a dereference, which takes a few cycles.

With any luck, as this was described, your knowledge of how an OS works warmed up and you realised, "oh, that's, that's actually how the OS kernel works". Yup. Obviously Linux isn't written in C++ and so it has to actually hand-write the code to make tables of functions, so actually it's a bit clearer in the source, we can see that sure enough the implementation of CIFS for example and the implementation of XFS, and the implementation of FAT all just provide tables of functions.

So if Casey is right, shouldn't Linux be crushed by some 20x faster OS made by Casey or similarly minded games programmers (maybe Jonathan Blow) without these low performance tables ? Nope, there two good things to know here.

Firstly, this flexibility is immensely useful and it turns out most users can't live without it. A product which is 20x faster but can't do what you need is at best irrelevant, at worst a nuisance, a distraction. The demo shape project really needs to be able to be extended for arbitrary shapes.

Secondly, and this is often much more important in practice yet Casey just completely ignored it, this is a fixed cost overhead. Multiplying two numbers together is almost no work, so the overhead dwarfs the real work done, but in real software we are often doing a lot of work, yes even despite the "Single responsibility" rule and as a result the overhead is negligible in practice.

While we're in here it's important to notice that the overhead occurs because of the actual indirection, which was incurred in the C++ by the use of virtual function calls to several distinct types of Shape, and in our Linux kernel example by the use of several different filesystems via a table. You are not paying this overhead merely for the existence of functions to allow separation of concerns although that's what Casey implies.

> You're denying yourself very basic performance techniques if you close your eyes and pretend to not see the internals of each shape.

You're spending an unaffordable amount of your finite engineering resource on handling other people's problems in all of your code if you insist on peering inside everything as Casey does in this toy example.

The reminds me of the argument in Hare (another programming language from people who figure they're smarter than everyone else) that they shouldn't provide generics because you ought to build a custom data type each time you need something reflecting exactly what you needed each time. When I read that I decided to look briefly at how their compiler used a hashmap (IIRC) and of course it was buggy because it's all hand rolled and so it has a typical mistake you might make in your first attempt with a hashmap - as every hashmap in a Hare program is its own custom first attempt. I believe they subsequently fixed the bug after I reported it, so that's nice - until next time.

> He works on games, where you not only have to iterate very quickly but you also may need to completely change direction halfway through the project

Casey's only notable actual game project completed seems to have been The Witness, Jonathan Blow's second and more ambitious but arguably less successful game. Casey has worked in the games industry for a long time, but like Blow he's spent a lot more time telling other people he could do better than he has spent on actually demonstrating that.

In the time it took Jon and Casey to ship one game, John Carmack's id Software shipped Doom, some Doom sequels and Quake and some Quake sequels. Jon and Casey are not people to take your cues from if you want to have agile software development practices or ship products in a timely fashion.

Do you remember the last time you had to do a tight calculation loop, and not only that, but one that significantly impacted the total runtime? Personally I do, it was roughly 15 years ago writing a raytracer.

I can imagine that happening in game/3D dev, DSP, emulators, ML, and maybe some other types of software, but even in those cases one already has dedicated libraries and hardware to extract the performance from where it can be extracted.

I mean, Python is slow as an old dog, yet it gets most of the ML fun.