4 ms·

This is a great exercise -- well done! What I try to convey to my students: * We write programs to solve problems. * The program is a model of the real-world

This is a great exercise -- well done! What I try to convey to my students: * We write programs to solve problems. * The program is a model of the real-world problem. * The better our model is, the easier it is to solve the problem. * Objects are excellent ways to model real-world "things" and manipulate them in our programs. I see online there's a movement that says OOP is "bad" but honestly in cases like this it makes perfect sense to me!

craftinator 6y ago
> I see online there's a movement that says OOP is "bad" but honestly in cases like this it makes perfect sense to me! TLDR; bad code practices make bad code. I think that this is confined to people who have a functional programming fetish, and those that worked at companies that drank the "OOP cool-aid" back in the late 90's early 2000's and built their codebase into massive, sprawling, strictly hierarchical monstrosities... I may have worked for one of these, and hated OOP with a passion till I realized that anything taken to an absurd degree is absurd. If we all just orient our models in relationships that make sense for what they do, OOP is fine.
- Dylan16807 6y ago
  > massive, sprawling, strictly hierarchical monstrosities > till I realized that anything taken to an absurd degree is absurd Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. If the default is an absurd degree, what does that say?
  - grenoire 6y ago
    That it's badly taught, not necessarily bad in itself.
    - Dylan16807 6y ago
      It makes a difference for categorizing and talking about OOP though. If the default level is good, and some people take it to absurd counterproductive levels, you need to give a bit of a warning. If the default level is absurd and counterproductive, but using a fraction that much is good, you need to approach the conversation in an entirely different way and "OOP is bad" is kind of correct and important to address.
      - craftinator 6y ago
        Again, your argument boils down to "doing bad stuff is bad", which I completely agree with.
        Dylan16807 6y ago
        "Do it the right way!" is not very helpful advice, though. We want to be able to say that one type of OOP is good and another is bad with relatively specific examples. We should have different terms for those types. You did the equivalent of replying to someone talking about nutritional tactics with "tl;dr eat healthy". Yeah, figuring out healthy is why we're here, looking at these different techniques and sub-techniques and figuring out at what point they become counterproductive.
  - craftinator 6y ago
    > Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. I actually had a great professor who'd worked at Microsoft during the dark ages, and taught OOP with very sensible "this can get way out of control if you drink the cool-aid" warnings. I also had a different professor that preached FP to an absurd degree, literally refusing to accept work that had a "too much OOP" flavor to it. Bad teaching and practices exist anywhere, hence my TLDR at the top.
ookdatnog 6y ago
My objection to this view is that, a "thing" is not the same thing as the data that represents it, and what data you use to represent the thing is dependent on what you intend to do with it. I think object-oriented programmers are more prone than others to wrongly equate their model with the thing they are modelling; the paradigm almost encourages that. I found this talk by Rich Hickey very persuasive: https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi....
brundolf 6y ago
Real-world code very rarely models real-world physical objects like this. This project is novel specifically because of that fact. And as soon as you step outside of modeling physical objects, OOP's benefits start to fall apart and you find yourself contorting abstract ideas into "objects" by way of concepts like Services, Strategies, Providers, Controllers, Adapters, etc (a whole lot of -ers, for the most part, which really drives home the fact that many of these objects only exist to "do" something, not to represent something).

craftinator 6y ago

> I see online there's a movement that says OOP is "bad" but honestly in cases like this it makes perfect sense to me! TLDR; bad code practices make bad code. I think that this is confined to people who have a functional programming fetish, and those that worked at companies that drank the "OOP cool-aid" back in the late 90's early 2000's and built their codebase into massive, sprawling, strictly hierarchical monstrosities... I may have worked for one of these, and hated OOP with a passion till I realized that anything taken to an absurd degree is absurd. If we all just orient our models in relationships that make sense for what they do, OOP is fine.

Dylan16807 6y ago
> massive, sprawling, strictly hierarchical monstrosities > till I realized that anything taken to an absurd degree is absurd Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. If the default is an absurd degree, what does that say?
- grenoire 6y ago
  That it's badly taught, not necessarily bad in itself.
  - Dylan16807 6y ago
    It makes a difference for categorizing and talking about OOP though. If the default level is good, and some people take it to absurd counterproductive levels, you need to give a bit of a warning. If the default level is absurd and counterproductive, but using a fraction that much is good, you need to approach the conversation in an entirely different way and "OOP is bad" is kind of correct and important to address.
    - craftinator 6y ago
      Again, your argument boils down to "doing bad stuff is bad", which I completely agree with.
      - Dylan16807 6y ago
        "Do it the right way!" is not very helpful advice, though. We want to be able to say that one type of OOP is good and another is bad with relatively specific examples. We should have different terms for those types. You did the equivalent of replying to someone talking about nutritional tactics with "tl;dr eat healthy". Yeah, figuring out healthy is why we're here, looking at these different techniques and sub-techniques and figuring out at what point they become counterproductive.
- craftinator 6y ago
  > Whenever I see OOP taught, the expectation is that every non-primative is an object in a massive hierarchy. I actually had a great professor who'd worked at Microsoft during the dark ages, and taught OOP with very sensible "this can get way out of control if you drink the cool-aid" warnings. I also had a different professor that preached FP to an absurd degree, literally refusing to accept work that had a "too much OOP" flavor to it. Bad teaching and practices exist anywhere, hence my TLDR at the top.

ookdatnog 6y ago

My objection to this view is that, a "thing" is not the same thing as the data that represents it, and what data you use to represent the thing is dependent on what you intend to do with it. I think object-oriented programmers are more prone than others to wrongly equate their model with the thing they are modelling; the paradigm almost encourages that. I found this talk by Rich Hickey very persuasive: https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi....

brundolf 6y ago

Real-world code very rarely models real-world physical objects like this. This project is novel specifically because of that fact. And as soon as you step outside of modeling physical objects, OOP's benefits start to fall apart and you find yourself contorting abstract ideas into "objects" by way of concepts like Services, Strategies, Providers, Controllers, Adapters, etc (a whole lot of -ers, for the most part, which really drives home the fact that many of these objects only exist to "do" something, not to represent something).