Live data from Hacker News

Inheritance was invented as a performance hack (2021)

catern.com

111–120 of 252 posts

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

#111
post #10

I'm not sold the evidence is there to show inheritance is a good idea - it basically says that constructors, data storage and interfaces need to be intertwined. That isn't a very powerful abstraction, because they don't need to be and there isn't an obvious advantage from doing so over picking up the concepts separately as required. And inheritance naturally suggests grouping interfaces into a tree in the way that se…

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…

>> People created AbstractFactoryFactoryBuilders not because they wanted to,

I don't think this is accurate. people created factories like this because they were limited by interface bounds in the languages they were coding in and had to swap out behaviour at run or compile time for testing or configuration purposes.

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

#112
post #90

Earlier quoted context omitted.

> a tree probably doesn't represent the fundamental truth of things It does. Trees appear in nature all the time. It's the basis of human society, evolution and many things. Most of programming moves towards practicality rather then fundamental truth. That's why you get languages like golang which are ugly but practical.

Botanical trees appearing in nature don't make them "the fundamental truth of things". And in what way are trees the basis of human society? Thats such a strange claim. Are you talking about family trees? Because they're actually directed acyclic graphs. Even if you want to claim that trees are a common data structure, that doesn't mean they're appropriate in any specific case. Should we therefore arrange all website…

"Taxonomies are entirely and completely worthless."

Hard disagree. Knowing that AES and Twofish are block ciphers is useful when dealing with cryptography. Many categories of algorithms and objects are naturally taxonomic.

Even HTML+CSS has (messy) inheritance.

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

#113
post #96
post #51

Earlier quoted context omitted.

> I don't think Inheritance is always bad - sometimes it's a useful tool. I can only think of one or two instances where I've really been convinced that inheritance is the right tool. The only one that springs to mind is a View hierarchy in UI libraries. But even then, I notice React (& friends) have all moved away from this approach. Modern web development usually makes components be functions. (And yes, javascript…

> The only one that springs to mind is a View hierarchy in UI libraries. I'd like to generalize that a little bit and say: graph structures in general. A view hierarchy is essentially a tree, where each node has a bunch of common bits (tree logic) and a bunch of custom bits (the actual view). There are tons of "graph structures" that fit that general pattern: for instance, if you have some sort of data pipeline DAG w…

turns out that using composition and polymorphism is usually simpler than inheritance in such cases.

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

#114
post #93

Earlier quoted context omitted.

The problem is of course that there is no useful default behavior you can define when the trait is so isolated and generic.

It doesn't have to be "so isolated". The trait can still have required methods that don't have a default implementation. Eg: trait Robot { fn send_command(&mut self, command: Command); fn stop(&mut self) { self.send_command(Command.STOP); } } struct BenderRobot; impl Robot for BenderRobot { // Required. fn send_command(&mut self, command: Command) { todo!(); } } This is starting to look a lot like C++ class inheritan…

> First, traits don't define any fields.

How does one handle cases where fields are useful? For example, imagine you have a functionality to go fetch a value and then cache it so that future calls to get that functionality are not required (resource heavy, etc).

    // in Java because it's easier for me
    public interface hasMetadata {
        Metadata getMetadata() {
            // this doesn't work because interfaces don't have fields
            if (this.cachedMetadata == null) {
                this.cachedMetadata = generateMetadata();
            }
            return this.cachedMetadata;
        }
        // relies on implementing class to provide
        Metadata fetchMetadata(); 

    }

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

#115
post #10

I'm not sold the evidence is there to show inheritance is a good idea - it basically says that constructors, data storage and interfaces need to be intertwined. That isn't a very powerful abstraction, because they don't need to be and there isn't an obvious advantage from doing so over picking up the concepts separately as required. And inheritance naturally suggests grouping interfaces into a tree in the way that se…

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 problem is every library and framework uses a ton of class hierarchies with big inheritance trees.

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

#116
post #51
post #43

Earlier quoted context omitted.

I don't think Inheritance is always bad - sometimes it's a useful tool. But it was definitely overused and composition, interfaces work much better for most problems. Inheritance really shines when you want to encapsulate behaviour behind a common interface and also provide a standard implementation. I.e: I once wrote a RN app which talked to ~10 vacuum robots. All of these robots behaved mostly the same, but each wa…

> I don't think Inheritance is always bad - sometimes it's a useful tool. I can only think of one or two instances where I've really been convinced that inheritance is the right tool. The only one that springs to mind is a View hierarchy in UI libraries. But even then, I notice React (& friends) have all moved away from this approach. Modern web development usually makes components be functions. (And yes, javascript…

I will tell you one example with inheritance: The Linux kernel.

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

#117
post #36

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…

Yeah, I have seen things like you describe. But I have also seen the same code, copy-pasted a dozen times throughout a codebase and modified over years. That is a much worse situation; the links between the abstractions still exist without the inheritance, but now they are untraceable. At least with inheritance there are links between the methods and classes for you to follow. Without it, you've got to crawl the entire codebase to find these things. OOP is easily the lesser of the two evils; without it, you're doomed to violate DRY in ways that will make your project unmaintainable.

I would even go so far as to argue that a small team of devs can learn an OOP heirarchy and work with it indefinitely, but a similar small team will drown in maintenance overhead without OOP and inheritance. This is highly relevant as we head into an age of decreased headcounts. This style of abandoning OOP will age poorly as teams decrease in size.

Keeping to the DRY principle is also more valuable in the age of AI when briefer codebases use up fewer LLM tokens.

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

#118
post #93

Earlier quoted context omitted.

It doesn't have to be "so isolated". The trait can still have required methods that don't have a default implementation. Eg: trait Robot { fn send_command(&mut self, command: Command); fn stop(&mut self) { self.send_command(Command.STOP); } } struct BenderRobot; impl Robot for BenderRobot { // Required. fn send_command(&mut self, command: Command) { todo!(); } } This is starting to look a lot like C++ class inheritan…

> First, traits don't define any fields. How does one handle cases where fields are useful? For example, imagine you have a functionality to go fetch a value and then cache it so that future calls to get that functionality are not required (resource heavy, etc). // in Java because it's easier for me public interface hasMetadata { Metadata getMetadata() { // this doesn't work because interfaces don't have fields if (t…

Getters and setters that get specified by the implementing type.

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

#119
post #95
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.

>no first-class support for them in the language. An interface is just a base class none of whose virtual functions have implementations. C++ has first class support for it. The only thing C++ lacks is the "interface" keyword.

The main reason (other than self-documentation) that some other languages separate interfaces form normal classes is that they only support multiple inheritance for interfaces.

C++ doesn't have this restriction, so interfaces would add very little.

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

#120
post #51

Earlier quoted context omitted.

> I don't think Inheritance is always bad - sometimes it's a useful tool. I can only think of one or two instances where I've really been convinced that inheritance is the right tool. The only one that springs to mind is a View hierarchy in UI libraries. But even then, I notice React (& friends) have all moved away from this approach. Modern web development usually makes components be functions. (And yes, javascript…

I will tell you one example with inheritance: The Linux kernel.

How does that work in a language without inheritance?

(yes, I guess it's the fake vtable of structure full of pointers)

Post reply on HN