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).

6
Brilliant analysis. Brian Will has articulated what I've felt for decades about OOP but could not wrap my arms around. Thank you!! On the particular KIND of bugs that we see in today's applications: The kind of bugs that OOP might produce vs the kind of bugs that procedural programming might produce have distinct characteristics. Take the case of Spellcheck as it operates erratically in certain versions of Word. Usually it sails right past one of my hyphenated words (in which I always use the hard hyphen), but if the moon is gibbous, then it chokes on the hyphenated word, and halts the Spellcheck routine to ask, "Resume?" That kind of behavior (linked to phases of the moon or to whether a fairy sneezed a prime number of times in heaven) is inconceivable for an application that was written procedurally, but it is just what one would expect from OOP where the actual lines of logic are subordinated and buried beneath layers of icky, half-baked doctrinaire. (As for the negative comments on this video, they smack of vested interest and group-think -- a reluctance to admit that one has spent so many years of his/her life, not to mention mucho dinero, on something that turns out to be ugly and bogus as a programming philosophy. Ken Kopelson's comment, with "this guy didn't learn properly," I found particularly offensive; Ken claims to have 'watched the video' but he couldn't have for his remark is a non sequitur.)

7
OOP does not need encapsulation. You can create an object-oriented language without a private keyword and purely use objects for data/function grouping. - In your object graph diagram thing, the whole idea is that each object manages its own state and there's no need for such a "god" object. External objects should never be able to poke the current object's state directly (hence why OOP almost always does come with encapsulation.) Of course any real program will need some sort of overall control (otherwise objects just sit there not even being instantiated) but that applies equally whether you use int main or public static final Main. - There's a huge divide between "in practice" and "in theory." You kind of touch on that here and there but the bottom line is that any paradigm will end up with people doing something stupid. Make pure functional programming the standard? You'll get people marking every single routine as a monad. Make procedural programming the standard? You'll get people that just toss everything into global variables. Not because that's the right way to do things, but because the possiblity exists (by necessity) and as long as it exists, someone will eventually decide to abuse the system. I don't know about the Java world but in C#, rarely do you see a (good) third party library with significant amounts of factories and managers and crap like that. Those kind of over-complicated designs are generally considered bad even in the OOP world (and we hear about them mostly in the context of "can you believe they did something this dumb?") I'm not saying OOP is a panacea.. I agree that its got its problems. All I'm saying is that any other methods will its problems as well. As the old saying goes, there is no silver bullet.

8
Not sure I agree with all of the premises in this video. Most of the issues are due to poor programming, not necessarily the language. In most systems I've worked on, you have two types of classes - "data" and "logic". One simply encapsulates the data you wish to work with and has associated getters/setters (and maybe a few utility methods), the other I guess you could call your procedural class which manipulates the data objects. I've seen these procedural classes called various things - business objects, technique classes, even managers as he states in the video. These classes typically do not have state. Nothing inherently wrong with this methodology, just comes down to properly structuring things to reduce complexity and reduce the probability of duplicate code/reinventing the wheel. Java, as it currently exists, doesn't have true encapsulation. Returned objects can be manipulated, giving the caller an indirect way to manipulate the state of another object. I agree to a certain degree with not breaking up functions simply due to lines of code. I call it bread crumb programming since you have to follow the trail of crumbs to figure out what is going on. I do not personally prefer inline functions, since it reduces readability. IMO if it's never going to be called in more than one place, it shouldn't be a separate function. I've worked with almost every type of language. Is OO perfect? No. But I'll take it over pure procedural any day.

9
think this video takes a very narrow view of Object-Oriented Programming. OOP as taught in a university or online, is not what it was originally when it was invented.
 * Alan Kay

19:32 "For object A to send a message to object B, A must hold a private reference to B" - Not true. Another way to approach this is to have object A emit an event that object B is listening for. Or for there to be some kind of lookup registry that contains the names of objects that are interesting to object A. Even if it did have a reference, what's wrong with that? The state is not actually shared, because objects B and C cannot modify the state themselves. In fact, they would not even be aware that there is any state. They are just passing messages which inform object A.

20:44 "You can impose rules through the accessor methods like..." - Well there's your problem. It's true that setter/getter methods make encapsulation almost pointless, but who says that's part of object oriented programming? You mean just because it's so common in Java, etc? I'd argue that getters/setters defeat the purpose of message passing, where the idea is that the object should be responsible for its own state. If you can reach in and play with that state, albeit with minor limitations, then how are you really encapsulating anything? Think about if a process could reach into the data of another process.

What would be the point of distinct processes then? True OO is better represented by Alan Kay, Dan Ingalls, David Ungar, etc, as in the following videos. https://www.youtube.com/watch?v=Ao9W93OxQ7U and https://www.youtube.com/watch?v=QjJaFG63Hlo

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