6 ms·

whats wrong with object oriented programming?

zwnow 3y ago
Too many distractions. Software architecture not transparent enough. Design pattern hell where it's not necessary. Too many devs who do not know what they are doing.
adrian_b 3y ago
OOP is great for some applications, e.g. for GUIs, but very bad for other applications, e.g. for scientific computing (where abstract types are very useful, but dynamic polymorphism and inheritance are harmful; moreover, the view that functions belong to data, instead of thinking about data as the things on which functions operate, is prone to inefficiencies whenever the amount of data is huge; one of the reasons why inheritance is harmful in scientific computing is that most operations with physical quantities have 2 or more arguments, and more often than not they are of different types; therefore any attempt to define those operations as member functions of some class that belongs to a hierarchy of classes makes no sense, even if all such operations are best defined as overloaded functions where a specific implementation is selected at compile time, based on the types of the arguments). Unfortunately, when OOP has become fashionable, its proponents have tried to convince everybody that OOP is the best paradigm for absolutely all programming problems, not only for those where OOP is indeed the best, and they have been rather successful for some time, which was bad for the software industry in general, resulting in many sub-optimal programs.
avianlyric 3y ago
Most real world problems don’t fit into neatly into hierarchical structures. OOP pushes you towards trying to model everything in the world an objects with strictly defined operations that can be performed on, where those actions are determined by the data type itself. You end up being forced to co-mingle your data structure design, with your data processing design. Which tends to be rather unhelpful. Keeping your data structures fairly separate from the processes/functions that operate on them makes it much easier to build composable software. Data structures tend to be very hard to change over time, because the migration process is always tricky. Any structure that’s exposed outside your programs address space, whether that be via an API, storage on disk or in a DB, needs a migration path so new code can deal with old structures correctly. On the other hand, algorithms operating on that data are trivial to change, there’s no migration risk, and indeed we should expect those algorithms to change often, as the requirements of the software change. In an OOP world, because you’re strongly encouraged to tightly bind your data structures to the algorithms that operate on them. You quickly end up in a horrible situation where changing your algorithms is very difficult without also being forced to change your data structures. Suddenly what should be a simple and easy change (introducing a new way of processing data), becomes difficult because coupling created by objects makes it hard to change the processing without also changing the data structures. In a simple “write-once” world, OOP is fine. But once you want to write software that’s expected to evolve and adapt over years, as business requirements change, OOP quickly becomes more a hinderance than help.
- deleted 3y ago
  [deleted]
- arein3 3y ago
  In OOP you can have data structures and algorithms separated. You can use composition over inheritance without issues. The fact that a language is strong typed and you get compilation errors if you forgot something is a big plus. OOP is fundamentally about no static variables.
  - gryn 3y ago
    don't conflate 'Objects' with 'Object Oriented Design', if you split your data Structures from you algos then your just using an OOP-language to do programming not doing OOP. strong typing has nothing to do with OOP. static variable are replaced by singletons and other similar in spirit objects. OOP today is a 'No true Scotsman' concept much like communism, agile, and other vague by design terms. You can't argue against it because every individual has at least one definition in his head and it shifts through the conversation toward the one that's not refuted by the claims. the intent of such concepts is to hit you in the feels and trigger some ideals inside you, so that you associate the positive feelings you have toward those ideals to the concept. if you argue about it as it is used in practice you will inevitably have someone bring up that java style OOP is not true OOP and that you should look intro Smalltalk or some other language that implement "Real OOP". since arguing about specifics is a losing battle, lets argue about the bigger picture, if we take the goals of alain kay like he talked about in many of his talks his goals was to make systems more like biogology, but as a system designer the last thing you want to do is that. we don't know much about biology, people in that field a still reverse engineering pre-existing designs to this day and not designing much of their own from scratch. If you design a system you want to have the most control and foresight in the dynamics of your systems, uncontrolled & unintended emergent effects are your source of problems. entangling data and behavior make your conceptual design state-space size explode, when you go full OOP you become an ontologist philosophizing about what is an X and what is an X-manager, X-Provider, ... and less of a system designer trying to make sure your system does not land in the wrong states.
HenriTEL 3y ago
Like everything it has its pro and cons. One of the con is that it favors a strong coupling between data and operations. Which mean that a change at one place is likely to change/break things elsewhere.
Rochus 3y ago
> whats wrong with object oriented programming? Nothing. It's just one of many useful tools we can use to develop software. It's like with food. Sometimes some people loudly claim that a certain food is unhealthy, and then a few months or years later you read the exact opposite. Fortunately, there are low-pass filters.
arein3 3y ago
If you want to write a script, OOP "kind of" nudges you towards making multiple data structures and "function" classes instead of having a simple 100 line function. And it is the wrong choice, if you need a script and can make that function in python. OOP, particularly Java, is good when you have a lot of functionality, especially if you can use already existing massive ecosystem. If I would have to write something from scratch, I would not use OOP, but if you need something fairly complicated, chance is there is already a generic solution available, and you need to costomize it, where Java is pretty good.
jokoon 3y ago
https://en.wikipedia.org/wiki/Object-oriented_programming https://en.wikipedia.org/wiki/Object-oriented_programming You can find some criticism points in there
mcguire 3y ago
I can't speak for Dijkstra, but in my view it is mostly about how it is taught. When you're learning OOP, you deal with questions like "is a Circle an Ellipse or is an Ellipse a Circle?" F'in' neither, actually. You end up "modelling" "business objects" in "code", leading to monstrosities like Hibernate. In reality, you have the real-world domain and you have the in-the-computer domain, and trying to make one look like the other is a mistake. OOP is a dandy way of managing some forms of complexity, but it's not often an especially good way of looking at most problems, much less the only way.

Too many distractions. Software architecture not transparent enough. Design pattern hell where it's not necessary. Too many devs who do not know what they are doing.

adrian_b 3y ago

OOP is great for some applications, e.g. for GUIs, but very bad for other applications, e.g. for scientific computing (where abstract types are very useful, but dynamic polymorphism and inheritance are harmful; moreover, the view that functions belong to data, instead of thinking about data as the things on which functions operate, is prone to inefficiencies whenever the amount of data is huge; one of the reasons why inheritance is harmful in scientific computing is that most operations with physical quantities have 2 or more arguments, and more often than not they are of different types; therefore any attempt to define those operations as member functions of some class that belongs to a hierarchy of classes makes no sense, even if all such operations are best defined as overloaded functions where a specific implementation is selected at compile time, based on the types of the arguments). Unfortunately, when OOP has become fashionable, its proponents have tried to convince everybody that OOP is the best paradigm for absolutely all programming problems, not only for those where OOP is indeed the best, and they have been rather successful for some time, which was bad for the software industry in general, resulting in many sub-optimal programs.

avianlyric 3y ago

Most real world problems don’t fit into neatly into hierarchical structures. OOP pushes you towards trying to model everything in the world an objects with strictly defined operations that can be performed on, where those actions are determined by the data type itself. You end up being forced to co-mingle your data structure design, with your data processing design. Which tends to be rather unhelpful. Keeping your data structures fairly separate from the processes/functions that operate on them makes it much easier to build composable software. Data structures tend to be very hard to change over time, because the migration process is always tricky. Any structure that’s exposed outside your programs address space, whether that be via an API, storage on disk or in a DB, needs a migration path so new code can deal with old structures correctly. On the other hand, algorithms operating on that data are trivial to change, there’s no migration risk, and indeed we should expect those algorithms to change often, as the requirements of the software change. In an OOP world, because you’re strongly encouraged to tightly bind your data structures to the algorithms that operate on them. You quickly end up in a horrible situation where changing your algorithms is very difficult without also being forced to change your data structures. Suddenly what should be a simple and easy change (introducing a new way of processing data), becomes difficult because coupling created by objects makes it hard to change the processing without also changing the data structures. In a simple “write-once” world, OOP is fine. But once you want to write software that’s expected to evolve and adapt over years, as business requirements change, OOP quickly becomes more a hinderance than help.

deleted 3y ago
[deleted]
arein3 3y ago
In OOP you can have data structures and algorithms separated. You can use composition over inheritance without issues. The fact that a language is strong typed and you get compilation errors if you forgot something is a big plus. OOP is fundamentally about no static variables.
- gryn 3y ago
  don't conflate 'Objects' with 'Object Oriented Design', if you split your data Structures from you algos then your just using an OOP-language to do programming not doing OOP. strong typing has nothing to do with OOP. static variable are replaced by singletons and other similar in spirit objects. OOP today is a 'No true Scotsman' concept much like communism, agile, and other vague by design terms. You can't argue against it because every individual has at least one definition in his head and it shifts through the conversation toward the one that's not refuted by the claims. the intent of such concepts is to hit you in the feels and trigger some ideals inside you, so that you associate the positive feelings you have toward those ideals to the concept. if you argue about it as it is used in practice you will inevitably have someone bring up that java style OOP is not true OOP and that you should look intro Smalltalk or some other language that implement "Real OOP". since arguing about specifics is a losing battle, lets argue about the bigger picture, if we take the goals of alain kay like he talked about in many of his talks his goals was to make systems more like biogology, but as a system designer the last thing you want to do is that. we don't know much about biology, people in that field a still reverse engineering pre-existing designs to this day and not designing much of their own from scratch. If you design a system you want to have the most control and foresight in the dynamics of your systems, uncontrolled & unintended emergent effects are your source of problems. entangling data and behavior make your conceptual design state-space size explode, when you go full OOP you become an ontologist philosophizing about what is an X and what is an X-manager, X-Provider, ... and less of a system designer trying to make sure your system does not land in the wrong states.

HenriTEL 3y ago

Like everything it has its pro and cons. One of the con is that it favors a strong coupling between data and operations. Which mean that a change at one place is likely to change/break things elsewhere.

Rochus 3y ago

> whats wrong with object oriented programming? Nothing. It's just one of many useful tools we can use to develop software. It's like with food. Sometimes some people loudly claim that a certain food is unhealthy, and then a few months or years later you read the exact opposite. Fortunately, there are low-pass filters.

arein3 3y ago

If you want to write a script, OOP "kind of" nudges you towards making multiple data structures and "function" classes instead of having a simple 100 line function. And it is the wrong choice, if you need a script and can make that function in python. OOP, particularly Java, is good when you have a lot of functionality, especially if you can use already existing massive ecosystem. If I would have to write something from scratch, I would not use OOP, but if you need something fairly complicated, chance is there is already a generic solution available, and you need to costomize it, where Java is pretty good.

jokoon 3y ago

https://en.wikipedia.org/wiki/Object-oriented_programming https://en.wikipedia.org/wiki/Object-oriented_programming You can find some criticism points in there

mcguire 3y ago

I can't speak for Dijkstra, but in my view it is mostly about how it is taught. When you're learning OOP, you deal with questions like "is a Circle an Ellipse or is an Ellipse a Circle?" F'in' neither, actually. You end up "modelling" "business objects" in "code", leading to monstrosities like Hibernate. In reality, you have the real-world domain and you have the in-the-computer domain, and trying to make one look like the other is a mistake. OOP is a dandy way of managing some forms of complexity, but it's not often an especially good way of looking at most problems, much less the only way.