Live data from Hacker News

Inheritance was invented as a performance hack (2021)

catern.com

201–210 of 252 posts

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

#201

Earlier quoted context omitted.

"But there's a reason the crowd is moving against inheritance" Yes, in our fad-chasing industry the pendulum has moved in the other direction. Let's wait few years. There is nothing wrong with OOP, inheritance, FP, procedural, declarative or whatever. What is bad is religious dogma overtaking engineering work.

I definitely agree that the crusade against inheritance is just a fad and not based on good reasoning. Every time people say "inheritance is garbage that people only use because they learned it in school" it pains me because it's like, really? You can't imagine that it's because those people have thought about the options and concluded that inheritance is the best way to model the problem they are facing? Contrary to…

I think there is a tendency in our industry to externalize imposter syndrome, blaming the tools rather than thinking "huh, I don't understand OOP yet."

Which doesn't mean everyone has to learn to understand OOP, but just because one person doesn't want to doesn't mean no one should.

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

#202

I think a lot of the arguments against inheritance come from C++'s peculiar implementation of it, which it clearly, ah, inherited from Simula. Slicing, ambiguous diamond inheritance, stuff like that are C++ problems, not inheritance problems. This isn't to say inheritance isn't problematic, but when you're making a properly substitutable sub- type of something, it's hard to beat.

What are examples of better inheritance?

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

#203
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…

"But there's a reason the crowd is moving against inheritance"

Yep: it requires skills that aren't taught in schools or exercised in big companies organized around microservices. We've gone back to a world where most developers are code monkeys, converting high-level design documents into low-level design documents into code.

That isn't what OOP is good for: OOP is good for evolving maintainable, understandable, testable, expressive code over time. But that doesn't get you a promotion right now, so why would engineers value it?

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

#204
post #192
post #17

Earlier quoted context omitted.

I'm on the fence about inheritance myself; I often regret having used it, and I never regret having not used it. On the other hand, it's awfully expedient. I designed and implemented a programming language called Bicicleta whose only argument-passing mechanism is inheritance, and I'm not sure that was a bad idea. The object-oriented part of OCaml, by the way, has inheritance that's entirely orthogonal to interfaces,…

1992 "Interfaces and Specifications for the Smalltalk Collection Classes" https://dl.acm.org/doi/pdf/10.1145/141936.141938

Very interesting work! It is an attempt to extract the interfaces that were in the minds of the implementors of the Smalltalk-80 system's collection classes, but which couldn't be expressed in the language itself, because it has no interface construct. That's what I meant by "Languages like Smalltalk (...) don't have interfaces at all."

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

#205
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…

I'm not sold on the evidence of much in the way of programming language features from the "object oriented" era. They were pushed by cultish types with little evidence. There was this assertion that all these things were wonderful and would reduce effort and therefore they must be good and we all must use them. We got object oriented everything including object oriented CPUs, object oriented relational databases, obj…

If encapsulation wasn't useful, we wouldn't write microservices.

If abstraction wasn't useful, we wouldn't use containers.

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

#206
post #79

I find that structural typing is the most useful thing and unfortunately few languages support it. I'd like a language where: - If I have a class Foo and interface Bar, I should be easily able to pass a Foo where Bar is required, provided that Foo has all the methods that Bar has (sometimes I don't control Foo and can't add the "implements Bar" in it). - I can declare "class Foo implements Bar", but that only means "…

I want the same things you do, and the closest I've found is writing Ruby with RDocs on all the public methods of a class.

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

#207
post #79

I find that structural typing is the most useful thing and unfortunately few languages support it. I'd like a language where: - If I have a class Foo and interface Bar, I should be easily able to pass a Foo where Bar is required, provided that Foo has all the methods that Bar has (sometimes I don't control Foo and can't add the "implements Bar" in it). - I can declare "class Foo implements Bar", but that only means "…

TypeScript does supports all of these - `C implements I` is not necessary but gives compile errors if not fulfilled. You can use `o satisfies T` wherever you want to ensure that any object/instance o implements T structurally. To verify a type implements/extends another type from any third-party context (as your third point), you could use `(null! as T1) satisfies T2;`, though usually you'd find a more idiomatic way…

The problem with TypeScript is that it is ridiculously verbose. It is everything people used to complain Java was back in the 90s.

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

#208

Earlier quoted context omitted.

From a very modified version of something I was working on recently, but with the stuff I couldn't do actually done here (and non-functionality code because of that, but is shows the idea) public interface MetadataSource { Metadata metadata = null; default Metadata getMetadata() { if (metadata == null) { metadata = fetchMetadata(); } return metadata; } // This can be relatively costly Metadata fetchMetadata(); } publ…

Here's my take on implementing this in rust. I made a trait for fetching metadata, that can be implemented by Image, Video, Document, etc: trait MetadataSource { fn fetch_metadata(&self) -> Metadata; } impl MetadataSource for Image { ... } impl MetadataSource for Video { ... } impl MetadataSource for Document { ... } And a separate object which stores an image / video / document alongside its cached metadata: struct…

When you call myImageInstance.fetchMetadata, what does it do? I don't know rust, so it's not clear to me how the value gets cached.

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

#209

Earlier quoted context omitted.

From a very modified version of something I was working on recently, but with the stuff I couldn't do actually done here (and non-functionality code because of that, but is shows the idea) public interface MetadataSource { Metadata metadata = null; default Metadata getMetadata() { if (metadata == null) { metadata = fetchMetadata(); } return metadata; } // This can be relatively costly Metadata fetchMetadata(); } publ…

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 implements MetadataSource from having to do so.

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

#210
post #98

Earlier quoted context omitted.

> Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself. That's true in C# but not in Java, so it's not something intrinsic to the notion of an interface. > Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties, and events - which are all fundamentally ju…

Making the class add 2 methods and a field for every place the interface would define a field adds noise. And if you have a class with 20 interfaces, that can be a lot of noise. When you consider that the class itself doesn't actually need to know anything about the field because only the interface uses them, it's just... ugly.

That's more of an issue with Java not having properties as first class language feature. In C#, you don't have to deal with fields at all, because auto-properties do all the same things:

   int Foo { get; set; }
Post reply on HN