3 ms·

I've long thought it was less OO that was problematic, and more the idea that you can make a taxonomy that covered your entire problem domain. Worse, people se

by taeric 3y ago

I've long thought it was less OO that was problematic, and more the idea that you can make a taxonomy that covered your entire problem domain. Worse, people seem to get caught up in the taxonomy for the sake of the taxonomy.

tempodox 3y ago
The thing is that OO forces taxonomy on you, especially if you have to deal with lots of inheritance.
- taeric 3y ago
  It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.
  - coldtea 3y ago
    >Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
    - taeric 3y ago
      I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
      - coldtea 3y ago
        >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
        taeric 3y ago
        OO with minimal hierarchies is basically leaning into metaphor for modeling techniques. It is akin to how a large number of informal models have worked for a long time. If you are focused on just the code organization side of the implementation, I can mostly agree with that. Even if I have grown fond of Java's much more predictable nature on where to find things. Modules or any other organization would have probably been fine.
coldtea 3y ago
Well, OO (as practiced, not what Alan Kay had in mind) is all about making a taxonomy. And the real problem I think is not all domains map to hierarchical relationships. Often it's forced, like trying to force push a square peg in a round hole.
- taeric 3y ago
  I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. Both ideas can be great, but I push more for both of them to be used in modeling the system. If there are different sections with "agency" in your system model, OO can make a ton of sense to work with those parts. If you have data getting passed around and worked with a lot, FP makes a ton of sense.
  - coldtea 3y ago
    >I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. I think it's not the same, because a taxonomy is a thing with limited descriptive power, and ultimately leading into a more or less arbitrary mapping, forced upon one's program design. Whereas "building your own algebra over the data in your system" has unlimited descriptive power, and is an abstraction over anything we do when we process data in a program. So, if we take "going to places" as a metaphor for programming, the first is like giving you the laws of motion and the ability to move in 4 dimensions as a tool (algebra), and the other is like telling you "you need to use a truck to travel, regardless of if you're going from LA to San Siego, from the bedroom to the WC, or from one floor to another" (OO).
    - taeric 3y ago
      Apologies, you seem to think I'm throwing them both under a lot of the same bus. That was not my full intent, and I will gladly cede that academia pushed OO far harder and to worse results than many functional things were pushed. That said, I think you are giving "algebras of data types" a bit too much credit here. The vast majority of the coding that is done will not be made better by elaborate ways of coding things above and beyond a relational language. Having an algebra is a happy convenience when it works. But I have been bitten by far too many failed attempts at making them work to think it is "unlimited descriptive power."

by taeric 3y ago

tempodox 3y ago

The thing is that OO forces taxonomy on you, especially if you have to deal with lots of inheritance.

taeric 3y ago
It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.
- coldtea 3y ago
  >Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
  - taeric 3y ago
    I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
    - coldtea 3y ago
      >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
      - taeric 3y ago
        OO with minimal hierarchies is basically leaning into metaphor for modeling techniques. It is akin to how a large number of informal models have worked for a long time. If you are focused on just the code organization side of the implementation, I can mostly agree with that. Even if I have grown fond of Java's much more predictable nature on where to find things. Modules or any other organization would have probably been fine.

coldtea 3y ago

Well, OO (as practiced, not what Alan Kay had in mind) is all about making a taxonomy. And the real problem I think is not all domains map to hierarchical relationships. Often it's forced, like trying to force push a square peg in a round hole.

taeric 3y ago
I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. Both ideas can be great, but I push more for both of them to be used in modeling the system. If there are different sections with "agency" in your system model, OO can make a ton of sense to work with those parts. If you have data getting passed around and worked with a lot, FP makes a ton of sense.
- coldtea 3y ago
  >I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. I think it's not the same, because a taxonomy is a thing with limited descriptive power, and ultimately leading into a more or less arbitrary mapping, forced upon one's program design. Whereas "building your own algebra over the data in your system" has unlimited descriptive power, and is an abstraction over anything we do when we process data in a program. So, if we take "going to places" as a metaphor for programming, the first is like giving you the laws of motion and the ability to move in 4 dimensions as a tool (algebra), and the other is like telling you "you need to use a truck to travel, regardless of if you're going from LA to San Siego, from the bedroom to the WC, or from one floor to another" (OO).
  - taeric 3y ago
    Apologies, you seem to think I'm throwing them both under a lot of the same bus. That was not my full intent, and I will gladly cede that academia pushed OO far harder and to worse results than many functional things were pushed. That said, I think you are giving "algebras of data types" a bit too much credit here. The vast majority of the coding that is done will not be made better by elaborate ways of coding things above and beyond a relational language. Having an algebra is a happy convenience when it works. But I have been bitten by far too many failed attempts at making them work to think it is "unlimited descriptive power."