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.

4

 * William Baric Unnatural? Our lives are made up of objects thought of in the way programming thinks of it. When I say "car" to someone, an image comes up, the know it has an engine and wheels and turns and speeds up. OOP takes advantage of this fact while procedural programming has no concept of a "car" or any other object. In procedural programming, there is no "car", but there does exist every element of that car, be it speed or state or color or whatever. OOP consolidates those into a template that all cars can be built on. It's a ridiculous statement to say OOP is unnatural, a kid will know what a "car" is before they know what a 2005 Mazda Miata is.

This comment is typical of not grasping that that object oriented programming, oop, is Struct stuffed procedural programming.


 * William Barric replies to DrMantisToboggan: ".... Objects don't act, they are acted upon. A circle doesn't draw itself, I draw a circle. That's why Object programming is completely unnatural.﻿...."

Which, stripping out the object metaphor is saying: .... procedural input to output mapping don't act.....  a category mistake has ruined computer science. In the real world, indeed rocks don't act, they are acted upon. There isn't a rock inside a computer.

5
Okay, Which one is more readable (also testing how far google went implementing markdown)?

bool carengine1poweredon=true; bool carengine2poweredon=true; Vector2 carposition1 = {3,4}; Vector2 carposition2 = {15,64}; //struct {int x; int y;} int carspeed1=60; //mph int carspeed2=59; //mph int cardirection1=35; //degrees int cardirection2=55; //degrees if (carengine1poweredon) { movecar(carspeed1,carposition1,cardirection1); }   if (carengine2poweredon) { movecar(carspeed2,carposition2,cardirection2); }

or this (OOP):

car Car1=new car(new Vector2(3,4),60,35); //position,speed,direction car Car2=new car(new Vector2(15,64),59,55); //position,speed,direction Car1.powerEngine(true); Car2.powerEngine(true); Car1.drive; //drive checks automatically whether or not engine is powered on and moves the car accordingly. Car2.drive; //drive checks automatically whether or not engine is powered on and moves the car accordingly.


 * The second one would be understand by even a young child, while first can barely be understood by even moderately experienced programmers. Of course, OOP is not a one size fits all solution and it will never be. It mostly has it uses where you can classify things into logical objects - labels, buttons, checkboxes, entities in a videogame, people being on a payroll at your company.﻿

That right there in the OP's comment is why OOP is ineffective. If you're working on a real life product it's unlikely you will have just one or two cars, you'll probably have lots of cross cutting concerns, and then the car class will need a ton of other classes (engine, tires, wiper fluid, ignition key) each with some extra class dependencies of their own. And then you need to start connecting the engine class with the fuel tank class with the tire class with physics engine class. You will end up with a horribly brittle class hierarchy that's painful to maintain and really hard to understand. But hey, you can write car.drive that does some stuff automatically behind your back, with lots of possibly-bug-producing side effects. Great success. Not to say that OP's procedural code is better, but when you write large programs you can write procedural code that's easier to maintain because there aren't so many dependencies to think of (if you write the code properly, that is, because you can write really bad procedural code as well).

objects are state
around 18min

allmhuran wrote: Here's just one, simply to prove the point. It's taken directly, verbatim, from the video. P1) Objects are state P2) Messages (strictly defined) can only send copies of state, not references C) Therefore, messages (strictly defined) cannot send object references

''The problem with this syllogism is what is meant with object?. https://en.wikipedia.org/wiki/Object_(computer_science) writes "... An object has state (data) and behavior (code). Objects can correspond to things found in the real world. So for example, a graphics program will have objects such as circle, square, menu ...". Your mental or behavioural "state" has nothing to do with domain range mapping of data, volitionalistic language allows for a category mistake when stuffing the functions inside a Struct. ''

MrSwanley
".....9 months ago (edited) An interesting video, but like some of the other theses mentioned, this one rather overstates its case. To pick one example: it claims that modifying a state by passing a message is just as bad as modifying a global variable. As someone who has written and had to maintain code over multiple decades, I can tell you that this is plain wrong. When you have a global variable you have intimate knowledge of and access to the implementation of a state. With messaging you do not. With messaging it is possible for the responsible object to be replaced by another module with a completely different implementation, without the client modules being affected. Code which relies on global variables will break. Code which does not will keep going. This is a huge difference, and not something to be glossed over.

Btw, I speak as somewho who developed through the Pascal and Modula-2 branchs of programming, eventually ending up doing modular programming in C (not C++). Yes, the full Petzold and Win32 API. I appreciate and occasionally use object oriented DESIGN (imho this talk rather conflates OOD and OOP), but I have no use for OOPLs (including C++) per se... I just find that they don't do anything to makes my life easier, which is what good design principles should be all about. ..."

links
oop