4 ms·

OOP is an industry of its own which generates a ton of incidental complexity. See "Object-Oriented Programming is Bad" by Brian Wills (https://www.youtube

by cutler 2y ago

OOP is an industry of its own which generates a ton of incidental complexity. See "Object-Oriented Programming is Bad" by Brian Wills (https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM) and most of Rich Hickey's excellent videos, especially his keynote at Rails Conf 2012 where he basically told the Ruby crowd they're doing it wrong (https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0).

ejflick 2y ago
> OOP is an industry of its own which generates a ton of incidental complexity. Code in any form can generate a ton of incidental complexity. The issue isn't the tool rather than the education to properly wield those tools. Especially when you introduce the team dynamic where everyone has varying understandings of what is being built and how it should be built.
lelanthran 2y ago
> OOP is an industry of its own which generates a ton of incidental complexity. And that "ton" is still miniscule compared to front-end development which almost completely eschews OOP and has 10x more incidental complexity. I guess my point is that, while OOP's incidental complexity is large, it's still insignificant compared to other technology stacks which developers are showing a great appetite for anyway. Things like "incidental complexity" is irrelevant to developers anyway, today, at the tail end of 2024. IOW, OOP introduces significantly less $BAD_THING, when the clear majority of developers don't even care about the quantity of $BAD_THING in the first place, making the whole "should we use OOP" argument moot. Doesn't matter if you use it or not, the extra introduced incidental complexity is still going to be insignificant due to the complexity load of the entire project, more so in front-end. Hence, there's no point in having the argument in the first place.
- bnchrch 2y ago
  Is your argument that 1. its ok to add incidental and unnecessary complexity 2. so long as it's less complex than your most complex component? Because that's a formula we can all agree leads no where good nor productive.
  - lelanthran 2y ago
    > Is your argument that > 1. its ok to add incidental and unnecessary complexity > 2. so long as it's less complex than your most complex component? That is not my argument.
chipdart 2y ago
> 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
kolja005 2y ago
As it pertains to Python in particular I think OOP is great for libraries but of limited usefulness at the application layer. Things like pytorch's nn.module IMO is a great abstraction, but every time I've tried to map some concrete business concept to an OOP construct I've regretted it.

by cutler 2y ago

ejflick 2y ago

> OOP is an industry of its own which generates a ton of incidental complexity. Code in any form can generate a ton of incidental complexity. The issue isn't the tool rather than the education to properly wield those tools. Especially when you introduce the team dynamic where everyone has varying understandings of what is being built and how it should be built.

lelanthran 2y ago

> OOP is an industry of its own which generates a ton of incidental complexity. And that "ton" is still miniscule compared to front-end development which almost completely eschews OOP and has 10x more incidental complexity. I guess my point is that, while OOP's incidental complexity is large, it's still insignificant compared to other technology stacks which developers are showing a great appetite for anyway. Things like "incidental complexity" is irrelevant to developers anyway, today, at the tail end of 2024. IOW, OOP introduces significantly less $BAD_THING, when the clear majority of developers don't even care about the quantity of $BAD_THING in the first place, making the whole "should we use OOP" argument moot. Doesn't matter if you use it or not, the extra introduced incidental complexity is still going to be insignificant due to the complexity load of the entire project, more so in front-end. Hence, there's no point in having the argument in the first place.

bnchrch 2y ago
Is your argument that 1. its ok to add incidental and unnecessary complexity 2. so long as it's less complex than your most complex component? Because that's a formula we can all agree leads no where good nor productive.
- lelanthran 2y ago
  > Is your argument that > 1. its ok to add incidental and unnecessary complexity > 2. so long as it's less complex than your most complex component? That is not my argument.

chipdart 2y ago

> 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

kolja005 2y ago

As it pertains to Python in particular I think OOP is great for libraries but of limited usefulness at the application layer. Things like pytorch's nn.module IMO is a great abstraction, but every time I've tried to map some concrete business concept to an OOP construct I've regretted it.