Tl;dr what exactly is wrong with OOP? I happen to know that many on Sup Forums do not like it

tl;dr what exactly is wrong with OOP? I happen to know that many on Sup Forums do not like it.

I have to prepare a presentation for college regarding OOP languages and I admit that my understanding on what it meant was superficial. So by doing further research, from what I can see, it puts way too much focus on object interaction; it feels like the logical structure of a program is merely a detail. Objects do interact with eachother and that's an important part of programming, and I can understand that focusing on data can be specially important in situations where, as pic related says, data must given special attention, like banking systems. That isn't the case for most software out there, but it seems like languages like Java and C++ are pretty much used everywhere, on every situation, irregardless of whether it is needed or efficient.

I have come to conclude that OOP isn't bad per se, but it's fairly overused and misused. Am I correct?

Other urls found in this thread:

youtube.com/watch?v=QM1iUe6IofM
utcc.utoronto.ca/~cks/space/blog/programming/CProgrammerOOView
wiki.c2.com/?DesignPatternsBook
yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html
arxiv.org/pdf/cs/0509027.pdf
twitter.com/AnonBabble

Hang on a minute, keep this thread bumped while I write your fucking college presentation for you, gaylord.

There is nothing wrong with oop.

I don't want or need you to do so. Just want to know your opinion.

OOP is slower and by nature more bloated. But it's far faster to produce deliverables with. It all depends on the situation.

If you find yourself using nouns to describe the process of solving a problem then OOP is great. If you don't need to or it doesn't come naturally, avoid OOP. Simple as that

not using the Golang

Abstractions hurt performance.

OOP would be nice if people could actually THINK about it and use the parts of OOP that make sense and complement their projects.

That's not what happens tho.
OOP in modern usage means blindly using bizarre patterns like setters and getters, polymorphism, classes, and encapsulation for EVERYTHING and not knowing why you do it.
It bloats up code something fierce and the only reason people continue to use it is because that's the way they were taught to program.
They can't even think programming without OOP because they don't understand what OOP does, "I just do it because I was taught that way :(("

>It bloats up code something fierce
No.
Shitty programmers will produce shitty code, regardless of the paradigm or language they're working in.

OO is hands down the best paradigm for large applications since the entire basis of it is re-usability, abstraction, and modularization.

youtube.com/watch?v=QM1iUe6IofM

OOP exists to limit the damage done by shitty programmers. If you had exclusively good programmers, they could write perfectly good code in a purely imperative style. But since you generally can't count on that in a large project, OOP helps prevent that (through things like encapsulation and information hiding) at the expense of making less efficient code that doesn't map as well to machine operations.

> more bloated by nature
lmao, if you don't use frameworks it won't be bloated at all.

>limiting efficiency in name of the lowest skilled programmers
Sounds... Stupid desu.

>thinking companies have unlimited resources
Sounds... Stupid desu.

Yes, they have limited resources, that's true. Scarcity is a reality.

And that's why they should only hire those who are the most efficient.

utcc.utoronto.ca/~cks/space/blog/programming/CProgrammerOOView

>And that's why they should only hire those who are the most efficient.
the ones who know their stuff are not the ones hiring though, they just have to damage control for all the trash that gets hired.

when I first got into programming I thought that I was really good at c++ and therefore oop as well. I could program just about anything, but even though I knew of fetures like virtual functions and inheritance, I didn’t understand when they would be useful. My code was messy and barely worked.

After reading gang of 4 my eyes were opened. It made me get why oop was useful. I think that your right that a lot of programers understand oop superficially, resulting in really bad code.

Then there are those that try to over apply concepts like design patterns. They just dont get when plain old data is the most efficient and effective solution and instead start forcing ideas that just dont fit.

So to answer your question there is nothing inherently wrong with oop. All paradigms have their own way of doing things that takes expeirence, knowlege, and critical thinking to do correcly.

How is OOP for games? I have no experience in game design, but apparently a lot of the stuff in games neatly fit into OOP-hierarchies

Not all problems can be solved efficiently or at all using Objects. Not all theoretical models can be approached like Objects.
Not everyone likes the lack of well-defined executive control when it comes to using objects. Constructor and destructor semantics, at least in C++, can be a headache at times. You needn't worry when you're simply calling your own functions.

Furthermore, data abstraction and encapsulation is perfectly possible in plain C, and all of these things are good in their own right and touted as strengths of OOP when they are actually strengths in themselves. You can decouple your program without making "Objects".

>apparently a lot of the stuff in games neatly fit into OOP-hierarchies
No, it really doesn't. Game engine developers are the loudest critics of OOP. Reshuffling inheritance hierarchies slows down development speed, and having to chase all those pointers slows down the engine itself. Modern game engines prefer data-oriented ECS architecture.

I see.

>data-oriented ECS architecture
Isn't ECS just another OOP design pattern/architecture?

OOP uses objects. Not OOP does not. Objects. Not objects is not good enough, Raymond.

Yes, that guy doesn’t know what he is talking about.

Prime example of someone who thinks that oop is just inheritance and classes.
>if there isn’t a big inheritence hierarchy it isn’t oop

You think skilled people aren't scarce?

They are far less of those people and they have to compete with other companies who also want to hire them. That means they have to use up more resources which they might not have.

>from what I can see, it puts way too much focus on object interaction; it feels like the logical structure of a program is merely a detail.
It pushes you to factor logic into discrete, independent pieces that ideally do not rely on the rest of the pieces to function. This is CRITICAL in large systems not just for division of labor, but for insuring that shit doesn't blow up in the future when you have to change things, fix bugs, add features, etc.

>and I can understand that focusing on data can be specially important in situations where, as pic related says, data must given special attention, like banking systems. That isn't the case for most software out there,
"Data is given more importance" is a false statement about OOP. "Data is encapsulated and hidden from code that should not manipulate it or rely on its structure and representation" is the correct statement. And that is crucial to larger systems.

>but it seems like languages like Java and C++ are pretty much used everywhere, on every situation, irregardless of whether it is needed or efficient.
OOP is better for most use cases. SP and FP have use cases where they really are better, but the cases are narrow.

That said:
* There are certainly examples of over engineered class libraries (Java) which are excessive (Java), confusing (Java), and unnecessary (Java).

* The lone coder of a small project does not run into the issues OOP solves as often as the team of a large project.

* FP is a meme and a religion right now, and it makes me cringe. FP has some very good use cases. But outside of those it's a disaster waiting to happen. Mr. Happy FP developer and his FP Meme Manager may not realize it today, but in many instances they are deploying code which will crumble in the future when significant revisions are necessary.

>It pushes you to factor logic into discrete, independent pieces that ideally do not rely on the rest of the pieces to function. This is CRITICAL in large systems not just for division of labor, but for insuring that shit doesn't blow up in the future when you have to change things, fix bugs, add features, etc.

>thinking this is a core aspect of OOP and not a side effect

>OOP in modern usage means blindly using bizarre patterns like setters and getters, polymorphism, classes, and encapsulation for EVERYTHING
Those are not "patterns." They are basic language features. Classes and get/set allow you to enforce encapsulation (which still is not a "pattern"). Polymorphism encourages code reuse.

A pattern would be something like observer, decorator, singleton, etc.

>It bloats up code something fierce
No it does not. OOP wasn't "slow" or "bloated" even in the 1990s and even with dynamic languages like objC.

>OOP exists to limit the damage done by shitty programmers.
It exists to limit the damage done by programmers, shitty or good. Our minds are neural nets and are damn good at abstraction, patterns, fuzzy logic, etc. But they are terrible when it comes to remembering many precisely defined, related things and predicting how a change in one will affect all the others.

That's why programming is a g-loaded task that can be difficult even for those with high IQs unless they have certain personality traits.

OOP does allow you to use lesser programmers on smaller tasks because those tasks tend to be encapsulated. The junior dev doesn't have to understand the whole system and can't fuck the whole system up. But architecting the system in the first place...the class libraries and interfaces...can be quite challenging and requires good devs.

>>thinking this is a core aspect of OOP and not a side effect

Oh for fuck's sake...read a fucking book. This is the problem OOP was intended to solve.

what do you mean by reading gang?

It's meme speak for a design pattern book with four authors whose names nobody remembers:
wiki.c2.com/?DesignPatternsBook

OOP usually depends on modifying an object's attributes which isn't pure

First decent post I've seen on Sup Forums in weeks.

Oop is actually faster because you're using algorithms programmed by experts.

libraries exist in imperative and functional programs?

Those aren't made by experts.

Objects are just a way of linking data together with the functions that manipulate the data. The only time objects don't make sense is when you're making a utility function which use no persistent data (only the parameters given and the variables needed to calculate the output). But it's still useful to put those in a namespace for naming/categorization sake.

An engine isn't the whole game. The games themselves are usually very well mappable to objects that interact with each other.

What? Do you mean the algorithms are designed by experts, and are only usable in OOP? Or that there exist expert implementations of common algorithms only in OOP languages?

What, do they think function pointers don't exist?

This whole "OOP adds actual bloat" thing needs to stop. The only difference between passing an object and passing a data structure is when you pass an object the compiler constructs any needed function map for you.

Hell, even if you put all possible actions in a single switch statement inside a function, you're STILL just doing a jump map only you're probably mapping a lot more data than each specific method needs.

Write a 300 line imperative style program, put that on a VCS and let other developers continue your work. Now do the same, but instead of doing a massive bloat, break it down into reusable pieces. Share the code once again and tell Me which one was easier to maintain/explain/debug. That's the whole point of OOP. Time is money, and in real world applications, decoupled code and well defined hierarchies are critical for systems

>when you pass an object the compiler constructs any needed function map for you.
And can do a better job than a mere human can. In strongly typed languages if it recognizes that a function call can only dispatch to one actual function it can skip the map and jump directly to it (at that location in the code). That happens more often then you might imagine even when people are trying to do proper OOP with interfaces and abstract parent classes/types.

But even in a very dynamic language, which always determines dispatch at runtime, OOP is not bloat. It wasn't even bloat on old Macs and UNIX workstations with 68030 processors.

This man gets it.

>OOP
>Flexibility is more
what

If you do such things you're just as big of a gaylord

Should we only use immutables e.g. only return new objects and/or copies?
Also make everything we can 'final' and always defensive copy parameters (if mutable)?

Instead of bothering with Functional nuances, use a language with proper support, instead of Java or C#.

pretty good
8/10 you got me

even in oop lambda functions are really usefull and a great way to make an algorithm really flexible.

yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

Inheritance is a meme. Interfaces are the way to go if you want polymorphism.

Nothing's wrong with OOP. Sup Forums are just hipsters.

which only works by reinventing vtables in C

Not much really.

You just have to be aware of the abstractions. As long as you know what it costs, and you know which prices are right, it's all good. You can always rewrite an important part of the code later anyway.

51stPBP

This whole thread is tl;dr.

OOP is basically a good idea, since it solves a lot of problems (high cohesion, low coupling) that made earlier software projects fail, google: "software crisis".

Some thoughts, though:

OOP langauges are either verbose and more complicated or they are simple and well designed, but slower. It's difficult to chose the right abstraction.

OOP influenced a lot of programming langauges. Even though Haskell guys like to brag about their "pure functional language", it's also a OOP language, wether they like it or not. Data structures and Monads are considered objects.

If OOP is so good, why is the Linux kernel written in C?

>Data structures and Monads are considered objects.
By whom, you?

Because Torvalds is a stubborn old git.

...

The only OOP you need is a struct inside of a header

>arxiv.org/pdf/cs/0509027.pdf

Some OOP things are neat, some take it to cultish levels. Imho the worst thing is when languages are specifically built for oop-style programming and for example don't let you define functions outside of a class.