5 ms·

> OOP is an industry of its own which generates a ton of incidental complexity. I think you're confusing "OOP is used in projects and I've seen accidental comp

> OOP is an industry of its own which generates a ton of incidental complexity. I think you're confusing "OOP is used in projects and I've seen accidental complexity in projects" with "OOP generates accidental complexity". The truth of the matter is that developers create complexity. It just so happens that the vast majority use OOP. I challenge you to a) start by stating what you think OOP is, b) present any approach that does not use OOP and does not end up with the same problems, if not worse.

galangalalgol 2y ago
a) I'm not sure what OOP is, and it doesn't seem like the people who tout it are either. I'm sure someone would look at code I think is good and call it OOP, and someone who wouldn't. It is so many buzzwords old at this point that using it is more a label of a viewpoint than a coding style. Combined with the book's apparent focus on TDD and carefully selecting names, it zeros me precisely in on a set of people I have worked with over the years. I don't, as a rule, like the code those people generate. b) The best style is no style, or at least pick a more recently popular dogma like FP, at least it gets you easy/safe parallelism in exchange for throwing some of the tools out of your toolbox.
- layer8 2y ago
  The core of OOP is encapsulation (into objects) and polymorphic interfaces. You program against interfaces with well-defined contracts. Implementation details are encapsulated behind those interfaces. The same interface can have different implementations. The same interface-typed variable can point to different implementations at different times within the same program execution. The caller who invokes operations on an interface is supposed to not care about the implementation details behind it, and thus be decoupled from them. Interfaces can have an inheritance/subtyping relationship. (Implementations may as well, but that’s optional.) This enables abstracting over the commonalities of several related interfaces without having to introduce an adapter/proxy object. That’s basically it.
  - ryao 2y ago
    After making those interfaces, the moment you need to do something that breaks those interfaces, you suddenly have a headache. I wrote a program in college that daemonizes by being an instance of a daemon class. Years later, people wanted the option to not daemonize. With C, this would be easy. With the way that I did things according to OOP principles in C++, I need to delete all of the code related to starting the program and write it from scratch. You could say that I just did not do it right, but that is the problem. You need to know precisely what the future will want to do it right and that is never possible to know in advance. OOP encapsulation is heavily overrated. There are a ton of headaches in C++ that do not exist in C because C does not try to do these things. Ever hear of the diamond problem? It does not exist in C. Nonsensical types that span multiple lines when trying to figure out why there is a type error? Not an issue in C either. C++ was advertised as reducing complexity, but in reality, it that encourages developers to drown themselves in complexity. If it were not for C never gaining a widespread STL equivalent, C++ would be far less popular. Sun Microsystems did make libuutil to provide such facilities, but sadly, it never caught on outside of Sun Microsystems technologies. The BSD sys/queue.h is the closest we have to it, but it is only for lists, and we need trees too to get a good equivalent to the C++ STL. That said, libuutil is available through ZFS, so it is not that people cannot adopt its awesome AVL tree implementation on other platforms. It is just that people do not know about it.
    - carmackfan 2y ago
      Your problem was a misuse of inheritance, not encapsulation or interfaces.
      - Sohcahtoa82 2y ago
        Misuse of inheritance is often the biggest generator of criticism of inheritance, sadly. People use the wrong tool for the job, or use it incorrectly, and then blame the tool. It's like using a hammer to play drums, obliterating the drum set, then ranting against hammers.
        2y ago
InDubioProRubio 2y ago
OOP is a mental crutch that breaks complex problems down into a easy mentally discoverable world/domain model with objects that have a life of their own, that is capable to derive correct results to complex problems via the relations of the objects. Meanwhile its creators can not hold the whole complexity in mind (often barely in spec) and still can produce a artifact that produces correct results.
nailer 2y ago
A. OOP as practically implemented for the last 25 years is glueing functions to state B. Functions and structs.
- corytheboyd 2y ago
  In the real world, where many people of varying backgrounds and skill levels are editing the same code, if the OOP method becomes a mess, why wouldn’t the functional approach also become a mess? I think that is more the point OP was making. In a vacuum with a single perfect Adonian programmer, seems like the OOP and functional approaches would becomes the same level of maintainable, because we’re in a vacuum of perfection anyway.
  - lioeters 2y ago
    In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. With the latter, it's simpler to replace a different function for any part of the logic, and the data is always just data; whereas with OOP the method is usually tied up with shared state and other functions.
    - chipdart 2y ago
      > In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. OP complained about accidental complexity, not subjective takes on how hard it is to refactor code. Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.
      - nineplay 2y ago
        > OP complained about accidental complexity, not subjective takes on how hard it is to refactor code. The biggest problem with accidental complexity _is_ how hard it is to refactor code. Refactoring code is a huge part of software development.

galangalalgol 2y ago

a) I'm not sure what OOP is, and it doesn't seem like the people who tout it are either. I'm sure someone would look at code I think is good and call it OOP, and someone who wouldn't. It is so many buzzwords old at this point that using it is more a label of a viewpoint than a coding style. Combined with the book's apparent focus on TDD and carefully selecting names, it zeros me precisely in on a set of people I have worked with over the years. I don't, as a rule, like the code those people generate. b) The best style is no style, or at least pick a more recently popular dogma like FP, at least it gets you easy/safe parallelism in exchange for throwing some of the tools out of your toolbox.

layer8 2y ago
The core of OOP is encapsulation (into objects) and polymorphic interfaces. You program against interfaces with well-defined contracts. Implementation details are encapsulated behind those interfaces. The same interface can have different implementations. The same interface-typed variable can point to different implementations at different times within the same program execution. The caller who invokes operations on an interface is supposed to not care about the implementation details behind it, and thus be decoupled from them. Interfaces can have an inheritance/subtyping relationship. (Implementations may as well, but that’s optional.) This enables abstracting over the commonalities of several related interfaces without having to introduce an adapter/proxy object. That’s basically it.
- ryao 2y ago
  After making those interfaces, the moment you need to do something that breaks those interfaces, you suddenly have a headache. I wrote a program in college that daemonizes by being an instance of a daemon class. Years later, people wanted the option to not daemonize. With C, this would be easy. With the way that I did things according to OOP principles in C++, I need to delete all of the code related to starting the program and write it from scratch. You could say that I just did not do it right, but that is the problem. You need to know precisely what the future will want to do it right and that is never possible to know in advance. OOP encapsulation is heavily overrated. There are a ton of headaches in C++ that do not exist in C because C does not try to do these things. Ever hear of the diamond problem? It does not exist in C. Nonsensical types that span multiple lines when trying to figure out why there is a type error? Not an issue in C either. C++ was advertised as reducing complexity, but in reality, it that encourages developers to drown themselves in complexity. If it were not for C never gaining a widespread STL equivalent, C++ would be far less popular. Sun Microsystems did make libuutil to provide such facilities, but sadly, it never caught on outside of Sun Microsystems technologies. The BSD sys/queue.h is the closest we have to it, but it is only for lists, and we need trees too to get a good equivalent to the C++ STL. That said, libuutil is available through ZFS, so it is not that people cannot adopt its awesome AVL tree implementation on other platforms. It is just that people do not know about it.
  - carmackfan 2y ago
    Your problem was a misuse of inheritance, not encapsulation or interfaces.
    - Sohcahtoa82 2y ago
      Misuse of inheritance is often the biggest generator of criticism of inheritance, sadly. People use the wrong tool for the job, or use it incorrectly, and then blame the tool. It's like using a hammer to play drums, obliterating the drum set, then ranting against hammers.
      - 2y ago

InDubioProRubio 2y ago

OOP is a mental crutch that breaks complex problems down into a easy mentally discoverable world/domain model with objects that have a life of their own, that is capable to derive correct results to complex problems via the relations of the objects. Meanwhile its creators can not hold the whole complexity in mind (often barely in spec) and still can produce a artifact that produces correct results.

nailer 2y ago

A. OOP as practically implemented for the last 25 years is glueing functions to state B. Functions and structs.

corytheboyd 2y ago
In the real world, where many people of varying backgrounds and skill levels are editing the same code, if the OOP method becomes a mess, why wouldn’t the functional approach also become a mess? I think that is more the point OP was making. In a vacuum with a single perfect Adonian programmer, seems like the OOP and functional approaches would becomes the same level of maintainable, because we’re in a vacuum of perfection anyway.
- lioeters 2y ago
  In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. With the latter, it's simpler to replace a different function for any part of the logic, and the data is always just data; whereas with OOP the method is usually tied up with shared state and other functions.
  - chipdart 2y ago
    > In my experience, the mess created using OOP is harder to untangle than the mess created using a functional approach. OP complained about accidental complexity, not subjective takes on how hard it is to refactor code. Even so, anyone who has any cursory experience with TypeScript projects that follow a functional style can tell you without any doubt whatsoever that functional style is incomparably harder to refactor than any "enterprise-grade" OOP.
    - nineplay 2y ago
      > OP complained about accidental complexity, not subjective takes on how hard it is to refactor code. The biggest problem with accidental complexity _is_ how hard it is to refactor code. Refactoring code is a huge part of software development.