Oop comments

comment 1
Those yelling "WHAT ABOUT BIG PROJECTS": An outspoken critic of OOP is Jonathan Blow. Here are two big projects he's done. You ever heard of Braid? It's a critically acclaimed video game from 2008 about time travel, which as you'd expect is pretty technically complicated, since it must efficiently store the state of every entity at every frame. 90 thousand lines of C++ code, all of them procedural. No STL. Runs perfectly on PC, Xbox 360 and PS3. You ever heard of The Witness? It's a critically acclaimed video game from 2016 about exploring an abandoned island, and it's got a triple-A-scope open world with a draw distance of infinity. 200 thousand lines of C++ code, all of them procedural. No STL. Runs perfectly on PC, Mac, PS4 Pro, and Xbox One. Now, tell me which OO software is more robust than these games.

1a
Your rant about floating point precision, aside from being strange, didn't actually address the robustness of the time travel feature. A modular object system that lets you add features and behaviours without changing the central structure of the code is bad. It may seem to increase development speed, but nobody has seriously demonstrated that to be true. From a design/quality standpoint, if you're inserting a feature into something like a game without considering the "cross-cutting concerns", you're basically doing a tack-on job. That means the feature is likely either bad, unnecessary, or doomed to yield a bad user experience. You are obligated to consider every interaction between components or else your software is incomplete. Nobody here encouraged copypaste programming, although the crusade against any and all code duplication is part of the reason why the world's software is terrible. Static analysis is good. Dynamic analysis is good, but only during development of course. Unit testing is garbage. Ignoring the fact that virtual functions aren't necessary or useful for any purpose, they eat some indeterminate amount of space from the beginning of any structure that uses them, meaning the structure's memory layout can no longer be optimized.

Calling a virtual function risks a cache miss dereferencing the object pointer, another dereferencing the vtable pointer, and a third dereferencing the function pointer. This gives virtual methods a minimum overhead of maybe ~3 cycles and maximum overhead of 600 cycles or more, not adjusted for branch misprediction. Iterating over a collection of objects with virtual methods will thrash the icache unless you sort by type. That means your objects must store their own type, at which point you could be using a switch. Philosophically, virtual functions are bad because they mandate that they remain abstract. Their implementation is opaque to the programmer, but experience with the real world shows that you actually have to care about the implementation of things. They are better done in userland than as a language feature, even considering compiler optimizations.

2
You talk a lot, you make 0 good point. Why are you arguing with us? You mixed functional programming and oop... Are you really a programmer? I'm really starting to doubt it. Especially what you said about memory. Not only you do not agree with the thing i told you you were very wrong about, but you seem to be in constant confirmation bias. You're like one of my friend who can't be wrong and want to argue but show no evidence, no example and brag about what he preach. Saying Functional doesn't contradict OOP is a joke. Poor attempt by your side. Saying Functionnal programming isn't possible in c++ is also a joke. I've yet to see OOP good side with exemple. That's my point. I see none. Most of the OOP stuff is optimised in assembly after to get it right. One of my friend work at Ubisoft and is one of the guy who does optimizing and it's pretty much a mess. He would love if people would stop programming in oop because it would made his job shorter and easier. YOu seem to not understand WHY C is still around and still strongly useful. Things that need critical stability like in hospitals or in military are made in C not, c++. Okay i'm wasting my time on you XD! Poor being.

3
The thing is, OOP is ineffective. The implementation is fundamentally hash maps with instantiated context-sensitive namespacing. And that's perfectly fine if that's all you use it for. But the second you start using objects to dictate control flow, you start building a babylon tower of interface spaghetti that no single man can fully understand in it's entirety.

My main issue with OOP is not just obfuscation of code but actual runtime performance decreases because of the heavy focus on the code modeling the real world instead of focusing on how data is actually being transformed. I don't care if my object hierarchy is laid out according to my mental model of the world if I'm constantly missing the cache because of it. OOP is terrible for games, for 2 reasons OOP is hard to paralelize and OOP is prone to cache misses also every major game till psx era was mostly written in assembly, not even C, heck even till ps3/360 era lot of assembly is used so fine control over memory can achieved

OOP fundamentally has 2 out of 3 of the right ideas (encapsulation and polymorphism); but how it executes them is terrible, and in the case of classical OOP, it pairs with inheritance over composition.

links
oop