Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inheritance was invented as a performance hack

catern.com

Post reply on HN
Print view View original

231–240 of 268 posts

Re: Inheritance was invented as a performance hack

#231

Post by ncmncm »

cout wrote: post #118
ncmncm wrote: post #111

The original inspiration for the idea really has nothing whatever to do with its subsequent architectural role, nor with its value as a mechanism. As a performance optimization, inheritance demonstrated value at a time when performance improvements were at least three orders of magnitude more important than they are today. People here like to disparage OO and inheritance, but the distaste clearly is just a reaction t…

IME the problem with inheritance in C++ is that it is so easy programmers reach for it instinctively, even when another tool might be a better choice in the long term. I definitely use inheritance in my c++ code, but as I've grown (and as the language has grown) I've found myself using it less and less. Perhaps that's the way it's supposed to be.

It is a problem with teaching. If you are taught to imagine yourself as an OO programmer using an OO language to produce OO designs, you will shoehorn in OO mechanisms even where they fit poorly. C++ has other organizational tools for these cases, so that there is little natural temptation to abuse OO for them.

People coming to C++ from impoverished languages like Java often fail to recognize bad habits they have internalized.

Re: Inheritance was invented as a performance hack

#232

Post by Serow225 »

titzer wrote: post #61
valenterry wrote: post #58

Earlier quoted context omitted.

I think for the usecase you mention, there is a different solution that I personally prefer. Optimally, if your language supports it, just define an interface with these 5 methods and then define extension methods that work on any type that implements the interface. The reason why this works is that all the other functions are usually helper functions / convenience functions and they only need the other 5 functions t…

Yeah, I generally like composition better, but sometimes the coupling between the base class and those subclasses that provide the 5 methods is just too strong to ignore, and if you break out the methods into another interface, then you are struggling to find a place to put the shared logic (which you proposed to do with extension methods). Your example with the counting stack made use of "super", which is always a r…

Re the shared logic, Java and C# have the concept of "interface default methods" which is what I'd use for your case, if I understand it right.

Re: Inheritance was invented as a performance hack

#233

Post by dang »

rectang wrote: post #194
dang wrote: post #57

Earlier quoted context omitted.

" Please don't sneer, including at the rest of the community. " https://news.ycombinator.com/newsguidelines.html

I take your critique, Dan, and in the future I'll try to find different ways to make similar points. I'm a bit deflated though, that now that this subthread has been demoted and dropped to the bottom, the usual "everybody knows inheritance sucks" comments are accumulating up at the top. I really enjoyed having a discussion for once that tried to suss out why inheritance, despite its flaws, was historically so semanti…

We downweight generic subthreads when we see them stuck at the top of a page. I've downweighted that one now. Obviously they're a problem (a big problem - maybe the biggest - because the most generic tangent from any topic is also the one that people are most familiar with, and familiarity breeds both repetition and upvotes). But the solution is not to have a generic tangent which is also a flamewar! However, you already agreed on that point and I don't mean to pile on.

Re: Inheritance was invented as a performance hack

#234

Post by toomanybeersies »

valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

Breaking the implementation of CountingStack by changing the implementation of Stack is the kind of stuff that unit tests should pick up. It's easy to write a test case for "CountingStack.pushAll() counts once per given element"

Re: Inheritance was invented as a performance hack

#235

Post by [deleted] »

kitd wrote: post #134
js8 wrote: post #132

Earlier quoted context omitted.

> which was a bit of an unguided mess at the time Oh, come on. There was https://en.wikipedia.org/wiki/Structured_program_theorem and https://en.wikipedia.org/wiki/Modular_programming . There was a discussion about functional programming, for example famous John Backus article - https://dl.acm.org/doi/pdf/10.1145/359576.359579 .

I was really thinking lower-level, specifically OOP, though yes I should've said it. OOP was going to save the world but no one knew how to design properly with it. GoF patterns were a set of off-the-shelf tactical designs intended to get you started in the right direction.

[deleted]

Re: Inheritance was invented as a performance hack

#236

Post by morelisp »

thewickedaxe wrote: post #19

I'm a little confused. Inheritance, types and all that stuff are just language concepts right? Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance? I'm sure the idea of inheritance was already there in language proofs. [I might be really really wrong here]

I would put OOP's solid theoretical foundations at the Liskov Substitution Principle invented in ~1988. This seems relatively late compared to OO's popularity. It was less than ~10 years between "structured programming" and the structured programming theorem (and lots of useful formal steps on the way), vs. 20+ for OOP and LSP (and at least at today's distance, LSP along with Meyer's contemporary substitution principles seems more like a sea change).

Re: Inheritance was invented as a performance hack

#237

Post by aflag »

toomanybeersies wrote: post #234
valenterry wrote: post #47

After reading all the comments of many confused and curious, here is when inheritance is bad and why so _in the absence of any performance considerations_. First, inheritance from an interface/trait is totally okay. The problem is class inheritance, meaning implementation inheritance. There are two cases: 1) you inherit from a class and only add methods but don't overwrite anything. This is the good case, you can do…

Breaking the implementation of CountingStack by changing the implementation of Stack is the kind of stuff that unit tests should pick up. It's easy to write a test case for "CountingStack.pushAll() counts once per given element"

Tests are not bullet proof and subtle errors may go uncatched. If you can completely eliminate a source of errors, why not?

Re: Inheritance was invented as a performance hack

#238

Post by aflag »

hota_mazi wrote: post #222
ratww wrote: post #123

Earlier quoted context omitted.

Code-reuse via "Implementation Inheritance" is completely unnecessary for specialisation or polymorphism. When someone says that "inheritance is bad for code reuse" they're not talking about interfaces, or using inheritance for polymorphism. They're strictly talking about sharing code using implementation inheritance, which is the thing that has been widely criticised for more than 30 years now. One can argue that ev…

Reusing implementation is the point. Here is more specifically what I meant with my comment about specialization above. There is a class with four methods, three of which are exactly what you need but the fourth one, you need to modify. Solving this with inheritance is trivial (extend and override). Solving this with any other paradigm is... much harder and requires a lot more boilerplate.

In functional programming you'd just create a new function that takes a value of the same type of those other 3 methods.

But anyway, creating a new method without changing any of the methods of the super class I think it's generally ok. The problems arise from modifying methods that the super class already implemented.

Re: Inheritance was invented as a performance hack

#239

Post by Someone »

kitd wrote: post #97
Arwill wrote: post #89

Earlier quoted context omitted.

I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them. One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the…

I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them. IIRC, there was impetus from Christopher Alexander's architectural "pattern language", and the desire to do something similar in software, which was a bit of an unguided mess at the time.

Simula 67 is (surprise) from 1967, Smalltalk-76 from 1976. Both supported objects and inheritance (http://progopedia.com/language/simula-67/, http://worrydream.com/refs/Ingalls%20-%20The%20Smalltalk-76%...)

“A pattern language” is from 1977; its application to programming from 1987 (http://c2.com/doc/oopsla87.html)

So, in the context of “Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance?”, I think this discussion is diverging a bit.

I would guess the idea of inheritance was already used in some assembly programs. It would start with people using structures that shared initial fields, and passing them to functions that didn’t care about the other fields (functions handling intrusive linked lists, for example). Passing a pointer to a function that _does_ know the exact type of the fields would be the next step.

The next step would be to allow heterogenous collections and use logic to discern between the various variants (many lisps do that by going through an “is it an atom?, is it a number? etc. chain, and likely did that years before Simula 67 appeared)

Chances are somebody also embedded a function pointer or two inside such objects, but I guess that would have come fairly late, as a function pointer in each object would have been expensive, memory-wise in the ‘60s and ‘70s.

Anyway, I think ‘inheritance’ indeed was invented/discovered, but gradually, and without explicitly naming it.

Re: Inheritance was invented as a performance hack

#240

Post by radlad »

slver wrote: post #224
rectang wrote: post #203

Earlier quoted context omitted.

But I don't think a "fully abstract class" is the same thing as an "interface", at least in Java? As far as I know, you can implement multiple "interfaces" but you can still only "extend" one abstract class, even if it is "fully abstract" in that it has no concrete member variables and all methods are abstract.

In Java it isn't but this is specific to Java (and clones of Java like C#). This is because Java has single-inheritance enforcement for classes. C++ for example has multiple inheritance. So the way you do an interface is you just write an abstract class, then extend it to implement it.

In my experience, whether you use an abstract class or an interface class as your reference depends very much on the problem you are trying to solve - specifically, is there common code shared across all implementations?
Post reply on HN