3 ms·

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 inheritanc

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.
  - rramadass 3y ago
    Your comment doesn't seem to be related to "Inheritance" at all but merely a opinion drawn from your anecdotal experience and hence not generalizable. As a counter-point i have read/written my fair share of hairy OO-code (mostly C++) and i can assure you that while it was a-lot-of-work sometimes (due to the complexity of the codebase itself) it was never "throw-up-my-hands" difficult once i applied some system and method. I hardly ever use a debugger but use tools like Doxygen/Cflow/cscope/etc. to get the static view of class hierarchy/call graph and profiler/printf trace/etc. to get the runtime dynamic call graph. These give me enough insight into the architecture to become productive. It is also a fact that OOD/OOP has been a enormous success in the real world in structuring "Frameworks" which give you a generic driver skeleton application for free into which you plugin your application specific code using (you guessed it!) "Interface/Implementation Inheritance". Finally i recommended Bertrand Meyer's OOSC2 book because nobody explains OOD/OOP better then him in a thorough and precise manner which clears almost all of one's doubts.
    - Fire-Dragon-DoL 3y ago
      I really appreciate your comment and it's absolutely true that I have no data. I don't think it's entirely anecdotal though, most newer languages and in case of JS newer paradigms are all strongly pushing against any form of inheritance, so this is an industry-wide change. I'm thinking of Go, Rust and the whole JS ecosystem that tries to write functional code (there might be others). I wouldn't put "class inheritance" in the same ballpark as "interface implementation", one is sharing code, the other is adopting a protocol. In my statement I was referring strictly to class inheritance for the purpose of code sharing. Unfortunately it's hard to bring up any meaningful numbers when talking about programming languages. Define success too: OOP has been used widely, but it's way harder to find numbers representing if the codebase is easier to navigate and maintain versus this new industry trend. Also, there is massive failure with OOP, it's just less documented than the success (look at all the companies that died due to poor software). And yes, all I can bring is an "industry trend", but the "enormous success" you are talking about in real world is effectively an industry trend too, but of course that's been going on for way longer. The tools you are talking about sound very interesting, but those are effectively "undoing" the inheritance, isn't that the case? The code should be written for humans, and you seem to be using a tool to literally put all the dynamic calls back into one place so that it's easier to follow. P.S. I'll check the book
- Fire-Dragon-DoL 3y ago
  Others have responded, but yeah, it's easy to understand inheritance, but doesn't make it suitable for designing software.
  - rramadass 3y ago
    https://news.ycombinator.com/item?id=36460680 https://news.ycombinator.com/item?id=36460680
    - Fire-Dragon-DoL 3y ago
      Thank you!
- lelanthran 3y ago
  I agree. > The basic idea behind "Inheritance" is simple and can be understood by all programmers. Not just by programmers. Just about everyone says "give me something like this, but with the following changed." That's the basic premise of inheritance and it clicks with everyone. I think the fact that when listing languages sorted by popularity, you can draw a line in the list, and everything above that line supports traditional OO while everything below that line provides band aids for it says a lot about how much OO clicks with programmers.

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.
- rramadass 3y ago
  Your comment doesn't seem to be related to "Inheritance" at all but merely a opinion drawn from your anecdotal experience and hence not generalizable. As a counter-point i have read/written my fair share of hairy OO-code (mostly C++) and i can assure you that while it was a-lot-of-work sometimes (due to the complexity of the codebase itself) it was never "throw-up-my-hands" difficult once i applied some system and method. I hardly ever use a debugger but use tools like Doxygen/Cflow/cscope/etc. to get the static view of class hierarchy/call graph and profiler/printf trace/etc. to get the runtime dynamic call graph. These give me enough insight into the architecture to become productive. It is also a fact that OOD/OOP has been a enormous success in the real world in structuring "Frameworks" which give you a generic driver skeleton application for free into which you plugin your application specific code using (you guessed it!) "Interface/Implementation Inheritance". Finally i recommended Bertrand Meyer's OOSC2 book because nobody explains OOD/OOP better then him in a thorough and precise manner which clears almost all of one's doubts.
  - Fire-Dragon-DoL 3y ago
    I really appreciate your comment and it's absolutely true that I have no data. I don't think it's entirely anecdotal though, most newer languages and in case of JS newer paradigms are all strongly pushing against any form of inheritance, so this is an industry-wide change. I'm thinking of Go, Rust and the whole JS ecosystem that tries to write functional code (there might be others). I wouldn't put "class inheritance" in the same ballpark as "interface implementation", one is sharing code, the other is adopting a protocol. In my statement I was referring strictly to class inheritance for the purpose of code sharing. Unfortunately it's hard to bring up any meaningful numbers when talking about programming languages. Define success too: OOP has been used widely, but it's way harder to find numbers representing if the codebase is easier to navigate and maintain versus this new industry trend. Also, there is massive failure with OOP, it's just less documented than the success (look at all the companies that died due to poor software). And yes, all I can bring is an "industry trend", but the "enormous success" you are talking about in real world is effectively an industry trend too, but of course that's been going on for way longer. The tools you are talking about sound very interesting, but those are effectively "undoing" the inheritance, isn't that the case? The code should be written for humans, and you seem to be using a tool to literally put all the dynamic calls back into one place so that it's easier to follow. P.S. I'll check the book
Fire-Dragon-DoL 3y ago
Others have responded, but yeah, it's easy to understand inheritance, but doesn't make it suitable for designing software.
- rramadass 3y ago
  https://news.ycombinator.com/item?id=36460680 https://news.ycombinator.com/item?id=36460680
  - Fire-Dragon-DoL 3y ago
    Thank you!
lelanthran 3y ago
I agree. > The basic idea behind "Inheritance" is simple and can be understood by all programmers. Not just by programmers. Just about everyone says "give me something like this, but with the following changed." That's the basic premise of inheritance and it clicks with everyone. I think the fact that when listing languages sorted by popularity, you can draw a line in the list, and everything above that line supports traditional OO while everything below that line provides band aids for it says a lot about how much OO clicks with programmers.