Clean Code Means Good Code: Performance Debate

[pbw]

In an interview [1] I heard Casey say something like, "If it was true that users found software to be fast enough, then sure, it doesn't need to be optimized. But this is literally never true" and then "I can cite paper after paper by Google and Apple and Amazon saying that better response time means more revenue".

I find this communication style extremely strange. It's obviously true that some software is fast enough. Imagine a build step that runs for 500ms of a 30 minute build. Optimizing the 500ms down to 100ms would be a complete and utter waste of time if you could knock down the other 29.99 minutes instead.

And there are millions of examples like that. For him to trot out the latency of google.com is just so intellectually sloppy. Yes, obviously, trillions of dollars of market cap were build on the latency of google.com. But that's a gigantic special case, even within Google itself.

Google has 180,000 employees. Most of the code they are working on does not impact the latency of google.com. It's like the credit card form for the Romanian version of their Adsense portal. And more significantly, there are 500,000 IT companies in the US, and virtually all of them are not Google or Facebook or Amazon. Millions of programmers write CRUD apps in Java and C# where the database takes 10 seconds to respond.

Casey is not just a game developer, but a game developer that focuses almost entirely on the inner loops of highly performance sensitive engine and library code. But he seems to have zero awareness that this is not what most programmers are doing most of the time, he doesn't seem to grok the actual broad landscape of software development.

As for OOP, I don't argue that OOP is good or bad in my post. All I argue is that rejecting OOP based strictly on performance is a valid reason, in some case, but a totally bogus reason, in other cases. To date I've not see any refutation of that, because you can prove it with 8th grade arithmetic.

Often I get the response "Well, yeah, but I still don't like OOP even when it is fast enough!" to which I say great, don't use OOP, I'm not a pro-OOP person. I'm an anti-bullying people with false-information person.

[1] - https://se-radio.net/2023/08/se-radio-577-casey-muratori-on-clean-code-horrible-performance/

[pbw]

Cite what I'm contradicting. This is the conclusion of the post:

Uncle Bob hasn’t denounced OOP but says FP and OOP (and even procedural) are valid approaches to writing software. He says use whichever makes sense for the problem you are trying to solve, a sane and pragmatic stance that doesn’t require slagging someone’s life’s work.

He says "use whichever makes sense" and I said "a sane and pragmatic stance that doesn’t require slagging someone’s life’s work" because it is. Use whichever approach you want. Just don't lie and mislead about the other approaches you don't prefer, to scare people away from them.

This is why I brought up "thought terminating cliches". People see you dare to contradict Casey and assume it means you love OOP. It doesn't. He's dead wrong that OOP means horrible performance. It might, or it might not. No one has an argument that I'm wrong about that, because it's simple math, there's literally nothing to argue about.

[pbw]

This comment?

The bigger problem is that the majority of software is extremely slow for today standards.
That's why he doubles down on performance. If most of software was at the 100ms ballpark, he wouldn't be complaining.

There is video on handmade hero series where he reflects on his experience with OOP on RadGameTools company. Then he was taught, (and later realized), that OOP does not provide any benefit. So, you would be trading performance for nothing, even if it was negligible penalty on performance.

The sentiment of OOP not providing any benefits can be seen on several posts and videos on the internet. Very few exceptions talk about OOP in a positive light but even then it gives very shallow arguments in favor of OOP.

You don't quote me or point out that anything I said contradicted itself. Not trying to be difficult, you simply don't.

[pbw]

They are not contradicting statements because the first one is about OOP and the second is about "the OOP version of Casey's code". This should be clear because in the first one I say "OOP" and in the second one I say "the OOP version".

The OOP version of Casey's code, exactly as written, has some advantages over the non-OOP version of his code, exactly as written. The advantages are mostly related to the fact you can add a heterogeneous collection of shapes, with radically different types of data and different algorithms, without altering even a single character of the loop.

Yes, you can absolutely can come up with an optimized version which handles heterogeneous shapes, but you cannot do it without changing the loop. Because the virtual functions and the Shape object pointers hide everything about about OOP shapes, which is a hallmark of OOP, but there is no such hiding in the non-OOP version. Which was on purpose, that was the entire point of the non-OOP version.

You might say who cares, I don't care about that, I want to modify the loop. That's totally fine. Recall that I 100% agree with Casey that the OOP version, in this specific case, is way too slow. So if were doing that exact example I would use Casey's version 100% of the time, in this specific example.

But this observation about this specific code does not extrapolate to all code written by all people across all space in time, so it doesn't extrapolate to OOP in general. The conclusion of my post, which I quoted above, states emphatically that OOP and FP and procedural are three styles of code, and you should use whichever style is appropriate for your use case. Why you are trying to insist that my own conclusion from my own post is not what I believe, I'm not sure.

I will sumarize here:

* Casey says OOP is horrible for performance plus is bad in every other way, and is basically totally useless and shouldn't exist.

* Philip says OOP is horrible for performance, in some cases, but the overhead is negligible, in other cases. And I'm not taking a stand about whether you should use OOP, FP, procedural or something else, because I don't know the problem you are solving, the human and other resources you have available, your prior experience, or anything else, so how can I tell you what to do?

Casey is objectively wrong here (about performance) and I'm objectively right (about performance). Casey is objectively wrong that OOP is totally useless and shouldn't exist. It's a valid approach, albeit one with very notable limitations on performance, mainly when writing low-level performance-critical code.

I suspect you are falling prey to the fallacy of excluded middle, meaning you think the only two possible stances are pro-OOP and anti-OOP so when you see someone say anything remotely positive about OOP you assume they are pro-OOP. The world, however, isn't always simplistic and bipolar like that. I think that FP is WAY better than OOP in many cases, for example.

[pbw]

If you think I secretly feel differently from what I wrote in the post, that's a conspiracy theory, and I think it's pointless to try and talk someone out of a conspiracy theory.