13 ms·

Yes. OOP pedagogy is completely messed up. First, examples are often unpractical and divorced from reality. The canonical meme examples of “Dog and Cat inherit

by whstl 2y ago

Yes. OOP pedagogy is completely messed up. First, examples are often unpractical and divorced from reality. The canonical meme examples of “Dog and Cat inherit from Animal” or “Car inherits from Vehicle” are not really applicable to Veterinary Clinic Software or Self Driving Cars. People use those kinds of examples to say that OOP is good at modeling reality, but business software is 90% of the time better served by a different level of abstraction. Second, a lot of descriptive information is passed as prescriptive. Patterns are a good example of how shoehorning concepts in a piece of software without having the knowledge to come up with it by yourself can make it worse, and yet teachers spend whole semesters dedicated to it. Third, inheritance is still being taught as a fundamental part of OOP from the beginning in every curriculum I have seen, only to have pretty much everyone else saying “prefer composition” down the line, after the damage is already done.

superxpro12 2y ago
I feel like if these classes focused on where objects can shine, like with dependency injection, we'd feel alot different about things. But instead we focus on modelling the problem, without demonstrating how to solve practical issues, and now we're left with this tool that noones knows how to use much beyond a CS203 exam.
- whstl 2y ago
  Indeed. Dependency injection, interfaces, runtime composition, passing objects/lambdas for configuration/changing behavior (Strategy pattern). Plus teaching proper separation of concerns rather than the "one line per method" from Clean Code. All this would lead to better software than the "Dog inherits from Cat" bs.
- DeathArrow 2y ago
  >I feel like if these classes focused on where objects can shine, like with dependency injection Dependency injection is not OOP. When used in an OOP context, it just solves an issue created by OOP. In an OOP context you can't call code from another object unless you have a reference to it. So you either instantiate the object or use DI to supply an object reference so you can call a method. In contrast to that, if you have functions as first class citizens or your code resides in a static class, you seldom need DI because you can call the function or method from wherever you need.
  - zelphirkalt 2y ago
    Or you can easily pass in a closure, that does what is needed. No objects or classes needed for that. You still have DI readily available.
mike_hearn 2y ago
It's pretty good at modelling reality and such hierarchies are useful. Look at the code of software that models reality: https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Engine/GameFramework/ASpectatorPawn https://dev.epicgames.com/documentation/en-us/unreal-engine/... The reason we don't tend to see such hierarchies used in clinic software is that RDBMS engines aren't OOP and don't model inheritance hierarchies well. Self driving cars are big piles of C++ so probably have plenty of OOP, albeit given the ML bent probably more for dealing with UI and sensors than modelling the nearby landscape. Inheritance is taught because most real OOP codebases use it extensively and it works OK. If you don't understand inheritance you can't understand the standard libraries of most OO languages, most UI toolkits etc.
- whstl 2y ago
  I'd argue that this is an artifact of history at this point. This was the popular style when unreal was made, and that's why it's there. Since Unreal is an old piece of software that powers older games, this code won't get removed. Because of compatibility. The industry (and this includes Unreal, albeit slowly) has been moving to runtime composition for a reason: it is simpler and more flexible. And much better at modeling reality. Your last paragraph pretty much sums it up: the main reason at this point for teaching implementation inheritance is because of legacy code bases. It can be a valid technique (I personally enjoy the Template Method Pattern, although it is today a maligned pattern) but it does causes more problems than it solves.
  - mike_hearn 2y ago
    Heh, there's nothing legacy about Unreal. It's the premier game engine in the world today and actively maintained by hundreds of developers. They're now pushing into film and do new releases regularly, often breaking backwards compatibility when they do. Where is this move away from OOP and inheritance? Even newly developed features like Nanite use it: https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Landscape/ULandscapeNaniteComponent https://dev.epicgames.com/documentation/en-us/unreal-engine/... But more importantly, is this take falsifiable? What does "old" or "legacy" mean? People have been pushing this line for at least 15 years here on HN, yet what we see in the most well funded and actively maintained codebases is lots and lots of inheritance, with no efforts to remove it. Not just Unreal but also Chrome, MS Office, iOS, Android, Java, and more, all use this technique with no ill effects as far as anyone can tell. When the maintainers talk about what issues they face and are putting refactoring efforts into, inheritance or OOP never seem to be on the list. In the Java case it's actually the opposite, they like to complain about people violating OOP encapsulation and want to make enforcement stricter. Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. What would it take to falsify the claim that inheritance is a legacy technique? Because I see no real evidence of it. Every codebase I've worked on has used it without anyone remarking on that fact, and it didn't seem to cause issues more often than other design patterns.
simulo 2y ago
These examples (dogs,cars...) are badly used in most programming books, but they can make sense if you show them in context of a small game or whatever else actually draws you an (inter) active virtual car or animal (which made OOP click for me, using processing). Printing "meow" and "woof" in the terminal, however, only makes sense as a demonstration if you already know what it should demonstrate.
- whstl 2y ago
  True, but even for games we already have a much better technique for doing it: runtime composition, which isn't really taught. The argument here is not so much that "implementation inheritance doesn't work at all" but rather that it is a limiting way of modeling that causes more problems than it solves, and teaching it is a problem in itself. Implementation inheritance should be a footnote given with a warning, rather than a main technique.
odyssey7 2y ago
It’s possible that OOP is taught in universities because professors who grew up with it already know how to fill a semester with this sort of content. The tail inheriting the dog. Of all the topics that CS programs teach, it makes intuitive sense that the practical ones in software engineering are the ones most likely to be taught in a way which is irrelevant or backwards. Academia is good at academic things, but its members are typically there in part because they do not have a calling towards practice. Perhaps the practical courses shouldn’t exist at all, but it’s tempting to marry the department with industry in some way. We don’t require philosophy majors to take courses in legal practice or whatever job they might take after graduation, because education is one thing and a career is another.
- whstl 2y ago
  That’s probably true, but I’m not sure if it’s the same with other paradigms. I had Pascal, Assembly and Haskell and it was quite practical and focused on universal concepts that apply to other paradigms and to software in general, it’s just OOP that has focus on concepts that are considered superfluous or damaging. I personally blame fashion. Patterns and inheritance became fashionable and people just assumed they are as foundational as things like “variables” or “functions” or “ifs”.
  - odyssey7 2y ago
    You’re making me realize that oop is essentially a framework. Other frameworks—-like jQuery, Express, or Handlebars—-get unfairly short-shrifted in the curriculum. One of the systemic dynamics with OOP is that Oracle invested itself into Java and also funds academic research. This might create a conflict of interest in designing the curriculum, but I don’t know if there are any checks for that.

by whstl 2y ago

superxpro12 2y ago

I feel like if these classes focused on where objects can shine, like with dependency injection, we'd feel alot different about things. But instead we focus on modelling the problem, without demonstrating how to solve practical issues, and now we're left with this tool that noones knows how to use much beyond a CS203 exam.

whstl 2y ago
Indeed. Dependency injection, interfaces, runtime composition, passing objects/lambdas for configuration/changing behavior (Strategy pattern). Plus teaching proper separation of concerns rather than the "one line per method" from Clean Code. All this would lead to better software than the "Dog inherits from Cat" bs.
DeathArrow 2y ago
>I feel like if these classes focused on where objects can shine, like with dependency injection Dependency injection is not OOP. When used in an OOP context, it just solves an issue created by OOP. In an OOP context you can't call code from another object unless you have a reference to it. So you either instantiate the object or use DI to supply an object reference so you can call a method. In contrast to that, if you have functions as first class citizens or your code resides in a static class, you seldom need DI because you can call the function or method from wherever you need.
- zelphirkalt 2y ago
  Or you can easily pass in a closure, that does what is needed. No objects or classes needed for that. You still have DI readily available.

mike_hearn 2y ago

It's pretty good at modelling reality and such hierarchies are useful. Look at the code of software that models reality: https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Engine/GameFramework/ASpectatorPawn https://dev.epicgames.com/documentation/en-us/unreal-engine/... The reason we don't tend to see such hierarchies used in clinic software is that RDBMS engines aren't OOP and don't model inheritance hierarchies well. Self driving cars are big piles of C++ so probably have plenty of OOP, albeit given the ML bent probably more for dealing with UI and sensors than modelling the nearby landscape. Inheritance is taught because most real OOP codebases use it extensively and it works OK. If you don't understand inheritance you can't understand the standard libraries of most OO languages, most UI toolkits etc.

whstl 2y ago
I'd argue that this is an artifact of history at this point. This was the popular style when unreal was made, and that's why it's there. Since Unreal is an old piece of software that powers older games, this code won't get removed. Because of compatibility. The industry (and this includes Unreal, albeit slowly) has been moving to runtime composition for a reason: it is simpler and more flexible. And much better at modeling reality. Your last paragraph pretty much sums it up: the main reason at this point for teaching implementation inheritance is because of legacy code bases. It can be a valid technique (I personally enjoy the Template Method Pattern, although it is today a maligned pattern) but it does causes more problems than it solves.
- mike_hearn 2y ago
  Heh, there's nothing legacy about Unreal. It's the premier game engine in the world today and actively maintained by hundreds of developers. They're now pushing into film and do new releases regularly, often breaking backwards compatibility when they do. Where is this move away from OOP and inheritance? Even newly developed features like Nanite use it: https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Landscape/ULandscapeNaniteComponent https://dev.epicgames.com/documentation/en-us/unreal-engine/... But more importantly, is this take falsifiable? What does "old" or "legacy" mean? People have been pushing this line for at least 15 years here on HN, yet what we see in the most well funded and actively maintained codebases is lots and lots of inheritance, with no efforts to remove it. Not just Unreal but also Chrome, MS Office, iOS, Android, Java, and more, all use this technique with no ill effects as far as anyone can tell. When the maintainers talk about what issues they face and are putting refactoring efforts into, inheritance or OOP never seem to be on the list. In the Java case it's actually the opposite, they like to complain about people violating OOP encapsulation and want to make enforcement stricter. Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. What would it take to falsify the claim that inheritance is a legacy technique? Because I see no real evidence of it. Every codebase I've worked on has used it without anyone remarking on that fact, and it didn't seem to cause issues more often than other design patterns.

simulo 2y ago

These examples (dogs,cars...) are badly used in most programming books, but they can make sense if you show them in context of a small game or whatever else actually draws you an (inter) active virtual car or animal (which made OOP click for me, using processing). Printing "meow" and "woof" in the terminal, however, only makes sense as a demonstration if you already know what it should demonstrate.

whstl 2y ago
True, but even for games we already have a much better technique for doing it: runtime composition, which isn't really taught. The argument here is not so much that "implementation inheritance doesn't work at all" but rather that it is a limiting way of modeling that causes more problems than it solves, and teaching it is a problem in itself. Implementation inheritance should be a footnote given with a warning, rather than a main technique.

odyssey7 2y ago

It’s possible that OOP is taught in universities because professors who grew up with it already know how to fill a semester with this sort of content. The tail inheriting the dog. Of all the topics that CS programs teach, it makes intuitive sense that the practical ones in software engineering are the ones most likely to be taught in a way which is irrelevant or backwards. Academia is good at academic things, but its members are typically there in part because they do not have a calling towards practice. Perhaps the practical courses shouldn’t exist at all, but it’s tempting to marry the department with industry in some way. We don’t require philosophy majors to take courses in legal practice or whatever job they might take after graduation, because education is one thing and a career is another.

whstl 2y ago
That’s probably true, but I’m not sure if it’s the same with other paradigms. I had Pascal, Assembly and Haskell and it was quite practical and focused on universal concepts that apply to other paradigms and to software in general, it’s just OOP that has focus on concepts that are considered superfluous or damaging. I personally blame fashion. Patterns and inheritance became fashionable and people just assumed they are as foundational as things like “variables” or “functions” or “ifs”.
- odyssey7 2y ago
  You’re making me realize that oop is essentially a framework. Other frameworks—-like jQuery, Express, or Handlebars—-get unfairly short-shrifted in the curriculum. One of the systemic dynamics with OOP is that Oracle invested itself into Java and also funds academic research. This might create a conflict of interest in designing the curriculum, but I don’t know if there are any checks for that.