>>9087883There is nothing wrong with OOP per se. Meaning subtyping, encapsulation and associating procedures with datatypes.
The problem lies in that students and substandard who've never worked on or written a large scale project before are being told that's the way to do things. They're being taught all kinds of "patterns" and "programming rules" on how it's supposed to be done, that these practices will improve code maintenance and readability. As anyone who has worked on large Java, C# or other OOP code bases can tell this is absolute bullshit. The more layers of abstraction you write the less clear your code becomes and the more you need to maintain.
The second problem is in the flawed mental model it teaches. It teaches us to think in terms objects that are abstractions of real world things with actions attached too them. Does a chair need to inherit from furniture? Does it need a sit method? Or does the sit method need to be part of Person? Ect... Seriously Java, does everything really NEED to be an object?
I've seen people go far into the rabbit hole with this, unnecessary inheritance structures, encapsulating data only to write routes around it, hours wasted in writing nothing but getters and setters, refactoring code a hundred times because they mental model of OOP conflict on how the objects need to be set up... It's endless.
Sometimes all you need is a simple function and data structure. And that's how we should teach programming. Work your way up to objects and patterns rather than using them as a starting point.
As a side effect it will also make learning programming much easier, because newbies don't have to juggle with retarded concepts and mental models.
Make programming about algorithms and data again.
