8 ms·

It's weird that so much of OOP back then was centered around deep class inheritance hierarchies as a means to share code when my favorite more modern languages

by jupp0r 3y ago

It's weird that so much of OOP back then was centered around deep class inheritance hierarchies as a means to share code when my favorite more modern languages (Rust and Go) intentionally leave out this part of OOP (thankfully, imho). An eye opener in respect to this was Sean Parent's excellent talk "Inheritance Is The Base Class of Evil" at GoingNative 2013 [1]. [1] https://www.youtube.com/watch?v=2bLkxj6EVoM https://www.youtube.com/watch?v=2bLkxj6EVoM

rramadass 3y ago
I really don't get why people keep repeating "class inheritance hierarchies are bad". If one understands Implementation vs. Interface inheritance and the intent behind each (the former strongly couples the code while the latter does not) then one can judiciously use inheritance techniques correctly. I recommend a study of Bertrand Meyer's OOSC2 and language Eiffel - https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...
- gyrovorbis 3y ago
  It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic? Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).
  - rramadass 3y ago
    >It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Right. By any measure OOD/OOP has been enormously successful in the real world and hence it is annoying to see blanket statements like "OOD/OOP/Inheritance/etc. is bad" on HN (i expected better). It is one thing to discuss cautions/caveats/different approaches but to dismiss the whole thing is quite silly. Hence my attempt at edification of the readers :-)
- jupp0r 3y ago
  The way I'm thinking about it (just a different expression of the exact same thought) is that inheritance as a means to share code is bad, while inheritance as a means to leverage polymorphism is good. Polymorphic classes can still share code, but this should be done using composition.
  - rramadass 3y ago
    > inheritance as a means to share code is bad, Not necessarily; if they are strongly coupled related concepts within the same module then it is perfectly fine (eg. private inheritance in C++). Here you are basically structuring for code reuse and not is-a relationship. >inheritance as a means to leverage polymorphism is good. This is the "standard" idea of inheritance i.e. sub-typing using Liskov Substitution Principle. > Polymorphic classes can still share code, but this should be done using composition. Not necessarily as a combination of the above two should make clear.
- Fire-Dragon-DoL 3y ago
  The reason is implicit makes really easy to miss things and the majority of software devs have very poor understanding of coupling. Consequence is if inheritance is a thing, you'll see monsters in the code. If inheritance is not available, the problem doesn't exist. Same goes for immutability, in the end our tools are tuning for the lowest performers
  - jupp0r 3y ago
    The ability to reason about code as you are reading it is not only important to "lowest performers".
    - Fire-Dragon-DoL 3y ago
      Absolutely agree, I very much prefer it
  - rramadass 3y ago
    Not true. The basic idea behind "Inheritance" is simple and can be understood by all programmers. Its realization through various language features and their combinations is what makes it somewhat confusing. Once explained and practiced with discipline, inheritance is very powerful. See my other comment: https://news.ycombinator.com/item?id=36428689 https://news.ycombinator.com/item?id=36428689 See also: https://thevaluable.dev/guide-inheritance-oop/ https://thevaluable.dev/guide-inheritance-oop/
    - jupp0r 3y ago
      Just because something is easy to understand at first does not make it suitable for designing maintainable software. I can understand the concept really well and it sounds completely appealing. When digging through the 18th code base with 12 deep inheritance hierarchies and various overwritten or not overwritten or combination thereof member functions where all you can do to follow control flow is to employ a debugger do you get the notion that this simple idea might not be so great after all.
- DarkNova6 3y ago
  I think inheritance is the most convenient thing which came out of OOP, but interfaces are the most valuable one. At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent. Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).
  - rramadass 3y ago
    You might find Program Development in Java: Abstraction, Specification, and Object-Oriented Design by Barbara Liskov with John Guttag interesting.
    - DarkNova6 3y ago
      I am always a sucker for good book recommendations. Thank you!
      - rramadass 3y ago
        The book is by the great Barbara Liskov herself (https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov) the pioneer of Abstract Data Types, Subtyping, OOD etc. It is basically a rewrite of their classic text Abstraction and Specification in Program Development (1986) with the example language now being Java. It is not a popular cookbook but a fundamental programming concepts book which needs serious study. I highly recommend it.
Kamq 3y ago
Yeah, that still weirds me out. Especially considering the other obvious mechanism of code reuse, the function.
- jupp0r 3y ago
  State can also be shared and reused together with functions operating on it - via composition.
  - Kamq 3y ago
    Sure, but that's desirable with, maybe, 5% of the code re-use opportunities I run across. I'm not saying to never use classes. I just got really confused about them being pushed as one of the dominant forms of code-reuse.
    - jupp0r 3y ago
      Agreed, I think it's been a hype at the beginning of OOP, then got overused in Java in the 90s and subsequently taught to every CS college student and it kind of stuck because in college, you don't get to maintain large software projects.
      - vaughan 3y ago
        OO is the king of the contrived example const dog = new Dog dog.woof() Now you see how simple OO is, let's build banking software.
lelanthran 3y ago
> modern languages (Rust and Go) intentionally leave out this part of OOP (thankfully, imho). Why thankfully? Some solutions are a natural fit for a class hierarchy. Having to hack in workarounds using traits or receivers is, like any band-aid, ugly as hell.
- jupp0r 3y ago
  There's a sizable chunk of people who think that the concept of inheritance for code sharing is causing more harm than good overall. These languages make it hard to do inheritance for exactly that reason.
  - lelanthran 3y ago
    > There's a sizable chunk of people who think that the concept of inheritance for code sharing is causing more harm than good overall. Maybe. What I've seen online is that there is a sizable chunk of people who think that the concept of inheritance is causing more harm than good overall. I don't see many adding the qualifier "for code sharing". > These languages make it hard to do inheritance for exactly that reason. It makes those languages a poor fit for some problem domains, like GUIs, for example. Or games. Or many enterprise systems. Which is why I am wondering why someone would be thankful that creating programs in certain very popular domains was made more difficult than the alternatives.
- gyrovorbis 3y ago
  "Thankfully" he says. Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this... Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).
mikro2nd 3y ago
OOP was never "centered around deep class inheritance hierarchies". It was centred around message passing and dynamic method dispatch. The only significance of inheritance is to resolve the receiver of a message. I feel strongly that most of the people who think OOP was bad are people who have only ever experienced C++/C#/Java or some even weaker instantiation of OOP. What do you suppose you're writing when you implement a (micro)service? It's nothing different than an object -- some implementation whose details you don't need to care about when you use it, which details can be changed at any time without disturbing clients (modulo idiocy), and an interface that you use to communicate with it via messages. And don't even get me started on the OO vs. Functional nonsense...
- gpderetta 3y ago
  Simula67, arguably the first OO language, was centered around inheritance. The other early major OO language was obviously Smalltalk which focused on message passing. Both C++ and Java were majorly influenced by Simula, while more dynamic languages take on aspects of Smalltalk.
  - pjmlp 3y ago
    Java is clearly influenced by Objective-C and Smalltalk in semantics. Not only their authors are on the record saying so, Java EE is inspired in an Objective-C framework (Distributed Objects Everywhere), and Hotspot is the evolution of Strongtalk JIT.
    - gpderetta 3y ago
      I'm sure that Objective-C and Smalltalk have also been strong influences, especially in the libraries. But I would say that the OO semantics are very Simula like. Can you really claim as Smalltalk inspired a language without an easy to use DoesNotUderstand? That's pretty much the basis for first class messages and transparent delegation. Also: https://www.youtube.com/watch?v=ccRtIdlTqlU https://www.youtube.com/watch?v=ccRtIdlTqlU edit: you could say that the JVM itself is more explicitly smalltalk-inspired as, AFAIK, has closer to fist class messaging support, but this power is hidden to the typical java program under a more interface oriented design. To reach the full power you have to escape form java into the meta-level via introspection.

by jupp0r 3y ago

rramadass 3y ago

I really don't get why people keep repeating "class inheritance hierarchies are bad". If one understands Implementation vs. Interface inheritance and the intent behind each (the former strongly couples the code while the latter does not) then one can judiciously use inheritance techniques correctly. I recommend a study of Bertrand Meyer's OOSC2 and language Eiffel - https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

gyrovorbis 3y ago
It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic? Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).
- rramadass 3y ago
  >It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Right. By any measure OOD/OOP has been enormously successful in the real world and hence it is annoying to see blanket statements like "OOD/OOP/Inheritance/etc. is bad" on HN (i expected better). It is one thing to discuss cautions/caveats/different approaches but to dismiss the whole thing is quite silly. Hence my attempt at edification of the readers :-)
jupp0r 3y ago
The way I'm thinking about it (just a different expression of the exact same thought) is that inheritance as a means to share code is bad, while inheritance as a means to leverage polymorphism is good. Polymorphic classes can still share code, but this should be done using composition.
- rramadass 3y ago
  > inheritance as a means to share code is bad, Not necessarily; if they are strongly coupled related concepts within the same module then it is perfectly fine (eg. private inheritance in C++). Here you are basically structuring for code reuse and not is-a relationship. >inheritance as a means to leverage polymorphism is good. This is the "standard" idea of inheritance i.e. sub-typing using Liskov Substitution Principle. > Polymorphic classes can still share code, but this should be done using composition. Not necessarily as a combination of the above two should make clear.
Fire-Dragon-DoL 3y ago
The reason is implicit makes really easy to miss things and the majority of software devs have very poor understanding of coupling. Consequence is if inheritance is a thing, you'll see monsters in the code. If inheritance is not available, the problem doesn't exist. Same goes for immutability, in the end our tools are tuning for the lowest performers
- jupp0r 3y ago
  The ability to reason about code as you are reading it is not only important to "lowest performers".
  - Fire-Dragon-DoL 3y ago
    Absolutely agree, I very much prefer it
- rramadass 3y ago
  Not true. The basic idea behind "Inheritance" is simple and can be understood by all programmers. Its realization through various language features and their combinations is what makes it somewhat confusing. Once explained and practiced with discipline, inheritance is very powerful. See my other comment: https://news.ycombinator.com/item?id=36428689 https://news.ycombinator.com/item?id=36428689 See also: https://thevaluable.dev/guide-inheritance-oop/ https://thevaluable.dev/guide-inheritance-oop/
  - jupp0r 3y ago
    Just because something is easy to understand at first does not make it suitable for designing maintainable software. I can understand the concept really well and it sounds completely appealing. When digging through the 18th code base with 12 deep inheritance hierarchies and various overwritten or not overwritten or combination thereof member functions where all you can do to follow control flow is to employ a debugger do you get the notion that this simple idea might not be so great after all.
DarkNova6 3y ago
I think inheritance is the most convenient thing which came out of OOP, but interfaces are the most valuable one. At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent. Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).
- rramadass 3y ago
  You might find Program Development in Java: Abstraction, Specification, and Object-Oriented Design by Barbara Liskov with John Guttag interesting.
  - DarkNova6 3y ago
    I am always a sucker for good book recommendations. Thank you!
    - rramadass 3y ago
      The book is by the great Barbara Liskov herself (https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov) the pioneer of Abstract Data Types, Subtyping, OOD etc. It is basically a rewrite of their classic text Abstraction and Specification in Program Development (1986) with the example language now being Java. It is not a popular cookbook but a fundamental programming concepts book which needs serious study. I highly recommend it.

Kamq 3y ago

Yeah, that still weirds me out. Especially considering the other obvious mechanism of code reuse, the function.

jupp0r 3y ago
State can also be shared and reused together with functions operating on it - via composition.
- Kamq 3y ago
  Sure, but that's desirable with, maybe, 5% of the code re-use opportunities I run across. I'm not saying to never use classes. I just got really confused about them being pushed as one of the dominant forms of code-reuse.
  - jupp0r 3y ago
    Agreed, I think it's been a hype at the beginning of OOP, then got overused in Java in the 90s and subsequently taught to every CS college student and it kind of stuck because in college, you don't get to maintain large software projects.
    - vaughan 3y ago
      OO is the king of the contrived example const dog = new Dog dog.woof() Now you see how simple OO is, let's build banking software.

lelanthran 3y ago

> modern languages (Rust and Go) intentionally leave out this part of OOP (thankfully, imho). Why thankfully? Some solutions are a natural fit for a class hierarchy. Having to hack in workarounds using traits or receivers is, like any band-aid, ugly as hell.

jupp0r 3y ago
There's a sizable chunk of people who think that the concept of inheritance for code sharing is causing more harm than good overall. These languages make it hard to do inheritance for exactly that reason.
- lelanthran 3y ago
  > There's a sizable chunk of people who think that the concept of inheritance for code sharing is causing more harm than good overall. Maybe. What I've seen online is that there is a sizable chunk of people who think that the concept of inheritance is causing more harm than good overall. I don't see many adding the qualifier "for code sharing". > These languages make it hard to do inheritance for exactly that reason. It makes those languages a poor fit for some problem domains, like GUIs, for example. Or games. Or many enterprise systems. Which is why I am wondering why someone would be thankful that creating programs in certain very popular domains was made more difficult than the alternatives.
gyrovorbis 3y ago
"Thankfully" he says. Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this... Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).

mikro2nd 3y ago

OOP was never "centered around deep class inheritance hierarchies". It was centred around message passing and dynamic method dispatch. The only significance of inheritance is to resolve the receiver of a message. I feel strongly that most of the people who think OOP was bad are people who have only ever experienced C++/C#/Java or some even weaker instantiation of OOP. What do you suppose you're writing when you implement a (micro)service? It's nothing different than an object -- some implementation whose details you don't need to care about when you use it, which details can be changed at any time without disturbing clients (modulo idiocy), and an interface that you use to communicate with it via messages. And don't even get me started on the OO vs. Functional nonsense...

gpderetta 3y ago
Simula67, arguably the first OO language, was centered around inheritance. The other early major OO language was obviously Smalltalk which focused on message passing. Both C++ and Java were majorly influenced by Simula, while more dynamic languages take on aspects of Smalltalk.
- pjmlp 3y ago
  Java is clearly influenced by Objective-C and Smalltalk in semantics. Not only their authors are on the record saying so, Java EE is inspired in an Objective-C framework (Distributed Objects Everywhere), and Hotspot is the evolution of Strongtalk JIT.
  - gpderetta 3y ago
    I'm sure that Objective-C and Smalltalk have also been strong influences, especially in the libraries. But I would say that the OO semantics are very Simula like. Can you really claim as Smalltalk inspired a language without an easy to use DoesNotUderstand? That's pretty much the basis for first class messages and transparent delegation. Also: https://www.youtube.com/watch?v=ccRtIdlTqlU https://www.youtube.com/watch?v=ccRtIdlTqlU edit: you could say that the JVM itself is more explicitly smalltalk-inspired as, AFAIK, has closer to fist class messaging support, but this power is hidden to the typical java program under a more interface oriented design. To reach the full power you have to escape form java into the meta-level via introspection.