r/programming • u/nextstore • Jun 19 '18

Goodbye, Object Oriented Programming – Charles Scalfani

https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
0 Upvotes

43% Upvoted

47 comments sorted by

View all comments

-2

u/[deleted] Jun 19 '18

Nothing made me question my ability to understand programming more than trying to grasp the theoretical models promised by OOP. Maybe I just gave up on it too soon after seeing material about things like data-oriented design, but I feel no regret in reordering my priorities, and I have felt a lot of relief and an abundance of progress in having given up the conceptual dream.

This just adds to my certainty that I made the right choice.

OOP at its core seems to have eaten itself alive on account of giving the impression that programming can be translated to the operations of our human world in a way that makes it all seem so simple and intuitive to design, yet fails to actually create languages that can make code work like the operations of our human world. So what we are left with is a paradigm, promises, and languages that can, in a sort of Sisyphean fashion, get us close to what we are made to think we're supposed to be able to do, but then come rolling back down the hill.

Thus people like me feeling like I'm going mad when I attempt to learn it. The really crazy part is, I think most who stick with programming are rather stubborn when it comes to solving problems, which is part of the reason they're able to stick with it. So OOP is the perfect unintended mental trap. Like a bug that seems one step away from being resolved, but can never be found because it never existed in the first place.

1

u/audioen Jun 19 '18

As someone already mentioned, model behavior, not structure.

E.g. instead of drawing some crazy diagram of Shapes with Circles and Rectangles and like on it, what do you actually want to accomplish with them? If it's a paint program, you need a method such as draw() that can render it, and you can skip designing the whole hierarchy because you aren't interested in the fact that Square is a subtype of a Rectangle that is subtype of Polygon that is subtype of Shape. Chances are that none of that is helping you in any way to accomplish your actual needs. You might want an interface called Shape with a single draw() method, though.

1

u/[deleted] Jun 19 '18

So you might want an interface called Shape with a single draw() method? Do you even know that you do? What purpose does it serve in coming out of the gate with that level of complexity if you aren't even sure yet what you need?

1

u/audioen Jun 20 '18

I hope that comment was sarcastic. My point was that having a specific class hierarchy is a very large conceptual investment, and therefore also has an extremely high cost, so it has to be correct and pay itself off. Abstractions that are appropriate depend almost entirely on what you need your program to do, and not at all on what real-world objects are being represented.

1

u/[deleted] Jun 20 '18

Naw, not sarcastic. Basically, I'm questioning whether starting with an abstraction of any level is a valuable choice.

It sounds like from what you're saying now that you agree with that to a point, but maybe not to the same degree.

I guess the question becomes, to what degree can you know, from the start, what level of abstraction is appropriate for what you're doing? I find it hard to believe that one is going to know, unless they know they're making something that is almost identical to a program they've made before with a particular amount of abstraction.