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

Inheritance was invented as a performance hack (2021)

catern.com

Post reply on HN
Print view View original

231–240 of 252 posts

Re: Inheritance was invented as a performance hack (2021)

#231

Post by nine_k »

wbl wrote: post #183
nine_k wrote: post #11

Earlier quoted context omitted.

But this may only happen when no virtual / overridden methods are involved, no VMT to look up in, no polymorphism at play. This is tanamount to composition, which should be preferred over inheritance anyway. In this regard, Go and Rust do classes / objects right, Java provides the classical pitfalls, and C++ is the territory where unspeakable horrors can be freely implemented, as usual.

Overriding is fine. The issue comes with polymorphism and would even without inheritance per se, as can be seen in Go where interfaces provide polymorphism without inheritance.

You're right, the issue comes from polymorphism, and from use of polymorphic values when the specific class cannot be determined statically. But this is sort of the point of polymorphism, can't do much about it, except maybe caching the looked-up value(s) when looping over a polymorphic collection.

Overriding may lead to other troubles though [1].

[1]: https://www.snopes.com/fact-check/shoot-me-kangaroo-down-spo...

Re: Inheritance was invented as a performance hack (2021)

#232

Post by svieira »

RHSeeger wrote: post #209
svieira wrote: post #148

Earlier quoted context omitted.

One way you could fix this with composition is: class CachedMetadataSource implements MetadataSource { CachedMetadataSource(MetadataSource uncachedSource) {} Metadata getMetadata() { if (metadata == null) { metadata = uncachedSource.getMetadata(); } return metadata; } }

I don't see how that solves the problem. It seems like Video will need to keep it's own copy of CachedMetadaSource, which points back to itself, and go through that access it's metadata in the getMetadata implementation it makes available to it's users. At that point, it might as well just cache the value itself without the extra hoops. The difficult part isn't caching the value, it's preventing every class that impl…

It would be the other way around. You wouldn't pass around the underlying suppliers directly, you'd wrap them. But if you must have state _and_ behavior, then `abstract class` is your friend in Java (while in Scala traits can have fields and constructors, so there is no problem).

Re: Inheritance was invented as a performance hack (2021)

#233

Post by josephg »

ninetyninenine wrote: post #229
josephg wrote: post #227

Earlier quoted context omitted.

Maybe that's our ultimate disagreement. I think the difference between composition and inheritance matters a lot. It changes how we break our software into modules. It sounds like you think of inheritance as being fundamentally the same as composition "with slight differences". Although even you admit that "Our brains cannot handle the complexity [of inheritance]". If that's true (and I think it is), the difference i…

>I'm curious if you'll still back the argument you've made here after you've been programming for 30 years too. You're clearly already suspicious of how and why inheritance makes code harder to understand. I suspect in a few years, you'll come around to my point of view on this. But I'd love to know if I'm wrong. I did insult your intelligence. Because when you said you have 30 years of experience I hear total arroga…

> The difference is skin deep. It's the emergent complexity that is NOT skin deep.

Yeah I agree with this. There's something about inheritance is more than skin deep. Something which changes how we conceive of our software. I agree that whatever that is, its quite important and impactful.

I could talk for days on what I think that difference is. I wrote a whole bit, but deleted it because I think I've said enough about what I think.

What do you think the difference is? How is it possible for composition and inheritance to be so different, if they're so alike on the surface?

Re: Inheritance was invented as a performance hack (2021)

#234

Post by pasc1878 »

layer8 wrote: post #168
lmm wrote: post #83

Earlier quoted context omitted.

Objective-C and Smalltalk were always niche languages, at least by comparison to Java and C#, and I think Smalltalk fans underestimate the value of many things. C++ does not (or at least did not at the time) have a concept of interfaces. There was a pattern in some development communities for defining interfaces by writing classes that followed particular rules, but no first-class support for them in the language.

Java having an explicit ”interface” construct is one thing I didn’t like about it, because it muddles the notion of a class implicitly having an interface (a notion that clearly exists in C and C++, by way of header files if nothing else) with that construct, while on the other hand there is no a-priori reason to have a distinction between Java’s interfaces and pure abstract classes. Both specify an interface to be i…

Java (following Objective-C) does need a differentiation between interface and pure abstract class - this is because it is single inheritance - a class can have any one class to inherit from but it can have many interfaces.

Re: Inheritance was invented as a performance hack (2021)

#235

Post by immibis »

osigurdson wrote: post #165
josephg wrote: post #103

Earlier quoted context omitted.

I have a slightly different take: I think every new technology or idea is created because it solves some problems, but in the long run, we'll discover that it creates other problems. For example, transpiling javascript, C++ OO, actors, coroutines, docker, microkernels, and so on. When a new idea appears, we're much more aware of the benefits it brings. But we don't know the flaws yet. So we naively hope there are no…

Although Java/C# make you put functions in a class, you aren't compelled to think of a class as a "noun". Just call it "Utils" or something like that. A class is just a thing that you can put functions and / or data in. Use that however you want.

The word "module" comes to mind. A class in Java can be viewed as a software module, of which more than one instance can be created. Sometimes, this is even the best way to view the class. Other times, it's better to view it as a class representing some noun.

A thing like a "comparator" or an "XYZ factory" is not a domain noun, but rather a pluggable code module.

Re: Inheritance was invented as a performance hack (2021)

#236

Post by simonebrunozzi »

eterm wrote: post #86
simonebrunozzi wrote: post #84

I know we're on Hacker News, but I would have preferred a more explicit title (programming language, not wealth across generations).

The first six words into the actual article makes it clear what it's about: > Inheritance was invented by the Simula language

Title of the Hacker News submission, not title of the article itself.

Re: Inheritance was invented as a performance hack (2021)

#237

Post by layer8 »

pasc1878 wrote: post #234
layer8 wrote: post #168

Earlier quoted context omitted.

Java having an explicit ”interface” construct is one thing I didn’t like about it, because it muddles the notion of a class implicitly having an interface (a notion that clearly exists in C and C++, by way of header files if nothing else) with that construct, while on the other hand there is no a-priori reason to have a distinction between Java’s interfaces and pure abstract classes. Both specify an interface to be i…

Java (following Objective-C) does need a differentiation between interface and pure abstract class - this is because it is single inheritance - a class can have any one class to inherit from but it can have many interfaces.

That doesn’t follow. The restriction could have been defined in terms of allowing at most one parent class to be non-pure-abstract. And there are lesser restrictions hat would have been conceivable as well. Java is single-inheritance only in the sense of the particular interface–class distinction it makes. For example, since Java 8 you can inherit method implementations from multiple interfaces.

Re: Inheritance was invented as a performance hack (2021)

#238

Post by ninetyninenine »

josephg wrote: post #233
ninetyninenine wrote: post #229

Earlier quoted context omitted.

>I'm curious if you'll still back the argument you've made here after you've been programming for 30 years too. You're clearly already suspicious of how and why inheritance makes code harder to understand. I suspect in a few years, you'll come around to my point of view on this. But I'd love to know if I'm wrong. I did insult your intelligence. Because when you said you have 30 years of experience I hear total arroga…

> The difference is skin deep. It's the emergent complexity that is NOT skin deep. Yeah I agree with this. There's something about inheritance is more than skin deep. Something which changes how we conceive of our software. I agree that whatever that is, its quite important and impactful. I could talk for days on what I think that difference is. I wrote a whole bit, but deleted it because I think I've said enough abo…

I literally wrote it above and you didn’t read. It’s a user interface issue, Let me copy it here:

But think about it. If you have a deeply nested Object where you don't use inheritance. Then all the objects have multitudes of redundant properties, doesn't that result in complex code as well? And how does nesting objects make it less complex then inheriting objects? It's more of code navigation problem in the sense that when you use inheritance and you look at a child derived from generations of inheritance it's just hard to read and figure out what the final object is because there’s no easy way to visualize or follow the derived properties.

With object composition the view is the same. You have an object that holds generations of nested objects. The difference is you can control click and follow the definition of the nested object so it's more visible.

Thus it seems to me the issue with the complexity is that inheritance simply does not give you a widget you can control click into easily to follow the definition and see what the derived methods are.

This whole problem is characterized by a user interface issue because it's not evident to me how an object with nested objects 1000000 layers deep is more complex then the same object derived from 100000 ancestors.

Think about the emergent complexity here. An object derived from inheriting a chain of 1000 inherited objects is actually less complex then that same chain of objects created via composition. Because duplicate properties don’t get overridden you have more data stored here then inheritance. It’s actually more complex.

The problem is in the user interface.

Create an IDE that automatically fills out all the derived methods of an object and allows you to control click to the ancestor where the derived method comes from and the issue seems to me to be solved.

Re: Inheritance was invented as a performance hack (2021)

#239

Post by osigurdson »

josephg wrote: post #36
osigurdson wrote: post #28

Earlier quoted context omitted.

Yeah ya... everyone likes to go on and on about how inheritance is the root of all evil and if you just don't use it, everything will be fine. Sorry, it won't be fine. Your software will still be a mess unless it is small and written three times by the same person who knows what they are doing. The bottom line is, no one ever really used inheritance that much anyway (other than smart people trying to outsmart themsel…

> The bottom line is, no one ever really used inheritance that much anyway If you think that, you have no idea how much horrible code is out there. Especially in enterprise land, where deadlines are set by people who get paid by the hour. I once worked on a java project which had a method - call a method - call a method - call a method and so on. Usually, the calls were via some abstract interface with a single imple…

Horrible code is a constant that will not be fixed by not using inheritance.

Re: Inheritance was invented as a performance hack (2021)

#240

Post by neonsunset »

osigurdson wrote: post #218
josephg wrote: post #216

Earlier quoted context omitted.

Yeah, the problem with OO isn’t really in the languages. The problem is in the community, and what people consider “best practice”. C#, Java and C++ are all arguably multi-paradigm languages. They give you a lot of flexibility in how you structure your code. C# and C++ support value types. Modern Java has great support for a lot of FP concepts too. So I agree with you. You can write good C# if you want to. The proble…

Maybe we need to tease "community" apart from language. Let's have Java / C# "A" people (who need at least 10 levels of inheritance, gotta use DI, insist on every character of SOLID (and actually remember and care about the Liskov substitution principle - and insist that it wasn't chosen simply because it starts with "L" and makes the acronym sound better) and have never written any code that added any value - only f…

> even feel slightly bad a about using generics.

Hey, struct generics are the go-to tool for zero-cost abstractions in .NET! No need to feel bad about them :)

Post reply on HN