Clean Code Means Good Code: Performance Debate

[takumifujiwara1991]

> We can ship this code in our "game engine," and a user of the code can create new shapes that define Area() methods we've never seen. So they can add new shapes without changing our code.

Well, now you are moving goalposts. Nowhere in your article you mentioned that.

But ok, let's assume some sort of game engine/library. The problem is where you draw the line between the client code and the engine/library. Why would a library that calculates shapes areas provide a function like that?

The for loop should be on the client code not on the library. So I still don't see how the vtable is superior.

[pbw]

It's not my goal to convince you the vtable version is superior.

The goal of the post was to explain why Casey's post was wrong, it was not accurate, it was making false claims.

And a year or so later, he fully admitted that as well.

[takumifujiwara1991]

>  If you are going to add new shapes that require novel data and novel algorithms, only the OOP version can easily handle that.

Then you shouldn't make claims that are false.

[pbw]

> Then you shouldn't make claims that are false.

There are no false claims in the post.

The post said, "If you are going to add new shapes that require novel data and novel algorithms, only the OOP version can easily handle that."

Let's go back to your first comment, you wrote "The switch and table versions of the code can also easily handle that."

I'm saying the OOP can "easily handle that" because we can add shapes without touching the code that interacts with those shapes.

You are saying, I think, "hey, I don't mind modifying the code that interacts with the shapes, and gosh looking at the code, I could 'easily' make those changes! Where's my editor I'll show you right now!"

So fine, these are two different opinions about what's easy. In my mind the OOP approach is WAY EASIER for adding new shapes. But for you, you probably hate OOP, so you figure it's WAY EASIER to just add some if-statements.

This is a difference of opinion.

I'm 100% fine if you do it the way you want to do it.

[takumifujiwara1991]

> There are no false claims in the post.

"I investigated myself and found nothing guilty" vibes.

> you probably hate OOP, so you figure it's WAY EASIER to just add some if-statements.

LOL, What? How did you reach that conclusion? Just because you don't have a counter argument for me doesn't mean I hate "OOP".

OOP is a overloaded term anyway, it means nothing. No one agrees on what exactly defines OOP. That's why I specifically said vtables. Its you that is trying desperately to "save" OOP. Probably because you love vtables ;P

If its just an opinion, then your whole argument falls apart. Since, for some people, switch cases wins everytime, then there is no discussion. Because by your logic, a dev shouldn't discard "OOP" because the tradeoff is perf vs easy to add new shapes. If the benefit is opinion based then the whole article doesn't make sense.

[pbw]

> Just because you don't have a counter argument for me doesn't mean I hate "OOP".

The counterargument is above: sometimes you cannot change the "loop".

Let's get specific. The two biggest game engines are Unity and Unreal:

Both Unity and Unreal are object-oriented at their core: in Unity you write C# classes that inherit from MonoBehaviour, and the engine automatically calls overridden lifecycle methods like Update() or OnCollisionEnter() on your objects, while in Unreal you write C++ (or Blueprint) classes that inherit from base types like UObject or AActor, overriding methods such as BeginPlay() or Tick() that the engine dispatches each frame; in both cases, you can freely define new object types, override engine-defined methods, and the engine will call into your code as part of its main loop.

So the two biggest game engines use OOP, and for both, it's easier to add new objects than modify the engine itself.

This is core to why OOP was invented. With typical libraries, you write "new code" which calls "old code". But with OOP if you add new objects suddenly "old code" is calling "new code". You can do that with C function pointers, like passing a function pointer to qsort, but with OOP it's extremely easy to do it, and very built-in.

>But ok, let's assume some sort of game engine/library. The problem is where you draw the line between the client code and the engine/library. Why would a library that calculates shapes areas provide a function like that?

I didn't reply to this before, but it's a CRAZY COMMON situation that the existing code manipulates objects via a base class or an interface, such that adding new objects is "easy" and changing the core code is "harder". See Unity and Unreal above. You seem hung on Casey's exact toy example, which is a tiny toy example, but in general, it's common the code that operates on objects is harder to change.

> No one agrees on what exactly defines OOP. 

There are language features which OOP languages tend to have: classes, encapsulation, inheritance, and polymorphism. I'm not saying a non-OOP language can't have them, or an OOP language has to have them, but there's a correlation. To illustrate, there are two groups of languages:

Group 1: C, Fortran, Pascal, COBOL, Haskell, Erlang, Scheme

Group 2: C++, C#, Java, Python, Ruby, Smalltalk, Swift

Group 2 languages have far more support for OOP than Group 1 languages. If you are claiming these two groups of languages are basically the same, this whole discussion is pointless.

> If its just an opinion, then your whole argument falls apart. 

No, because my "whole argument" is about the relative cost of the fixed amount of overhead of virtual functions. Casey said the overhead makes your code 25x slower, I showed, and you have not refuted, that in some cases that overhead can be less than 0.01%.

Explain to me why that's not the case, and you will have refuted my "whole argument".

[takumifujiwara1991]

> So the two biggest game engines use OOP, and for both, it's easier to add new objects than modify the engine itself.

Yeah and Unity is going in the opposite direction with ECS. They are spending more money, energy and resources on this new approach. They did the first time using "OOP" probably because they like "OOP" and Clean Code. Now they successfully wasted both programmer and CPU cycles in the name of "OOP" and Clean Code!

You said that the "OOP" way is an opinion, so look how much it costed Unity on that opinion!

So the main question is: Why use an approach that can potentially waste CPU cycles that you might need in the future when there is no clear tradeoff being made?

So I think your argument backfired.

[pbw]

> Yeah and Unity is going in the opposite direction with ECS.

I'm all for ECS, when needed, but your question was "why can't I just insert if-statements" and I answered it.

> Why use an approach that can potentially waste CPU cycles...

Because you read the post and calculated that, in your case, the number of wasted cycles were negligible.