3 ms·

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/documentatio

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.
  - whstl 2y ago
    A programming style isn't automatically "good" just because it's financially and technically unfeasible to migrate to something else overnight. The reason Unreal uses inheritance is because this is what people did in 1998. The reason it can't stop using is because it's too late to change. There's nothing more to it.
  - the-smug-one 2y ago
    > Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. Do you think that inheritance had something to do with that?
  - kryptiskt 2y ago
    > Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. Haskell still is a thing, and Pandoc and shellcheck are widely used, if you aren't, you're missing out. And Haskell impressed Tim Sweeney enough that a whole bunch of Haskell people are working on Epic's Verse language.
    - mike_hearn 2y ago
      Well, Verse has both OOP and inheritance: https://dev.epicgames.com/documentation/en-us/uefn/subclass-in-verse https://dev.epicgames.com/documentation/en-us/uefn/subclass-... Epic is a very successful software company, they're familiar with FP/Haskell, and their new language has classes with inheritance. There is no evidence here of any shift away from the concept, let alone Unreal being legacy! Apple is the same. Swift deviates from other languages in many ways, but it has inheritance: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/inheritance/ https://docs.swift.org/swift-book/documentation/the-swift-pr... Jetbrains also designed a new language in the past decade, and it has inheritance. Nobody objected (pun intended) and people use it successfully. So I think that kind of reinforces my point that the dislike of OOP and inheritance is largely restricted to the HN bubble.
  - loup-vaillant 2y ago
loup-vaillant 2y ago
> It's pretty good at modelling reality and such hierarchies are useful. There's just one problem: code should not deal with a model of the world. It should deal with a model of the data. A chair is a chair you'd say? Well it depends. Is it a background texture you'd never get close enough to notice it's flat? Is it a static mesh that never moves, and could be considered part of the ground itself? Is it something you can grab and displace? Can it be swung like club, or thrown like a rock, and do damage if it hit you or an NPC? Depending on what you want to do with that chair, the data describing it will be very different. And if you have any performance constraint that data will likely be put in very different structures or systems, from landscapes to two-handed weapons. The very concept of "chair" at this point is mostly moot. > Inheritance is taught because most real OOP codebases use it extensively and it works OK. Avoiding inheritance would have worked better in most such codebases. I have seen things… > If you don't understand inheritance you can't understand the standard libraries of most OO languages, most UI toolkits etc. Any item behind "etc"? Because so far those two are the only example of inheritance being kind of mandatory. And I'm not even sure about standard libraries, the C++ STL is very light on inheritance, and I see very little of it in Python (at least as a user). I guess Java makes heavy use of it.
- mike_hearn 2y ago
  I gave other examples for "etc", like game engines. Plenty of others out there. Web server frameworks and so on also use it. Feel free to argue with the Unreal devs that they're doing it all wrong, or make a competing game engine that never uses inheritance. Whilst "chair" is not something you'll see in their C++ code (too specific), objects like players, static meshes, lights etc are and I guess it works fine for them. Avoiding inheritance doesn't necessarily work better. I too have seen things, and what you find in languages that don't have inheritance is that they often end up growing libraries that emulate it, just in hacky ways and far too late. That's pretty common in C codebases. As a simple example of the problems anti-OOP ideology creates, try using Jetpack Compose (a sort of React on steroids) to make a UI where later you decide you want a particular customization to every instance of a particular control in your app. Have fun... the way you customize anything is to wrap that composable in another composable and manually forward all the properties. Want to change the way buttons work? Find every place where a button is used and replace it with the name of your new button, then keep your new MyButton up to date as the underlying library adds new properties. Hope there are enough callbacks to do what you need, and try to avoid being distracted by them all when you're just using a button instead of customizing it. Want to write code that's generic over certain kinds of controls? You just ... can't ... because controls aren't objects now, they're functions. You end up manually implementing inheritance without the aid of the compiler or language features like visibility modifiers. It's far from ideal.

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.
- whstl 2y ago
  A programming style isn't automatically "good" just because it's financially and technically unfeasible to migrate to something else overnight. The reason Unreal uses inheritance is because this is what people did in 1998. The reason it can't stop using is because it's too late to change. There's nothing more to it.
- the-smug-one 2y ago
  > Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. Do you think that inheritance had something to do with that?
- kryptiskt 2y ago
  > Meanwhile heavily hyped successors that lacked it, like Haskell, have vanished without a trace, leaving not even one widely used program in their wake. Haskell still is a thing, and Pandoc and shellcheck are widely used, if you aren't, you're missing out. And Haskell impressed Tim Sweeney enough that a whole bunch of Haskell people are working on Epic's Verse language.
  - mike_hearn 2y ago
    Well, Verse has both OOP and inheritance: https://dev.epicgames.com/documentation/en-us/uefn/subclass-in-verse https://dev.epicgames.com/documentation/en-us/uefn/subclass-... Epic is a very successful software company, they're familiar with FP/Haskell, and their new language has classes with inheritance. There is no evidence here of any shift away from the concept, let alone Unreal being legacy! Apple is the same. Swift deviates from other languages in many ways, but it has inheritance: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/inheritance/ https://docs.swift.org/swift-book/documentation/the-swift-pr... Jetbrains also designed a new language in the past decade, and it has inheritance. Nobody objected (pun intended) and people use it successfully. So I think that kind of reinforces my point that the dislike of OOP and inheritance is largely restricted to the HN bubble.
- loup-vaillant 2y ago

loup-vaillant 2y ago

> It's pretty good at modelling reality and such hierarchies are useful. There's just one problem: code should not deal with a model of the world. It should deal with a model of the data. A chair is a chair you'd say? Well it depends. Is it a background texture you'd never get close enough to notice it's flat? Is it a static mesh that never moves, and could be considered part of the ground itself? Is it something you can grab and displace? Can it be swung like club, or thrown like a rock, and do damage if it hit you or an NPC? Depending on what you want to do with that chair, the data describing it will be very different. And if you have any performance constraint that data will likely be put in very different structures or systems, from landscapes to two-handed weapons. The very concept of "chair" at this point is mostly moot. > Inheritance is taught because most real OOP codebases use it extensively and it works OK. Avoiding inheritance would have worked better in most such codebases. I have seen things… > If you don't understand inheritance you can't understand the standard libraries of most OO languages, most UI toolkits etc. Any item behind "etc"? Because so far those two are the only example of inheritance being kind of mandatory. And I'm not even sure about standard libraries, the C++ STL is very light on inheritance, and I see very little of it in Python (at least as a user). I guess Java makes heavy use of it.

mike_hearn 2y ago
I gave other examples for "etc", like game engines. Plenty of others out there. Web server frameworks and so on also use it. Feel free to argue with the Unreal devs that they're doing it all wrong, or make a competing game engine that never uses inheritance. Whilst "chair" is not something you'll see in their C++ code (too specific), objects like players, static meshes, lights etc are and I guess it works fine for them. Avoiding inheritance doesn't necessarily work better. I too have seen things, and what you find in languages that don't have inheritance is that they often end up growing libraries that emulate it, just in hacky ways and far too late. That's pretty common in C codebases. As a simple example of the problems anti-OOP ideology creates, try using Jetpack Compose (a sort of React on steroids) to make a UI where later you decide you want a particular customization to every instance of a particular control in your app. Have fun... the way you customize anything is to wrap that composable in another composable and manually forward all the properties. Want to change the way buttons work? Find every place where a button is used and replace it with the name of your new button, then keep your new MyButton up to date as the underlying library adds new properties. Hope there are enough callbacks to do what you need, and try to avoid being distracted by them all when you're just using a button instead of customizing it. Want to write code that's generic over certain kinds of controls? You just ... can't ... because controls aren't objects now, they're functions. You end up manually implementing inheritance without the aid of the compiler or language features like visibility modifiers. It's far from ideal.