Inheritance was invented as a performance hack • Hacker News Board

Re: Inheritance was invented as a performance hack

#191

Post by cyphar » Fri, Apr 30, 2021, 1:53 PM UTC

rst wrote: post #184

dwattttt wrote: post #143

Earlier quoted context omitted.

You actually can have a single queue that handles the different cases. You want dynamic dispatch for that, the syntax looks like this (quick addition to the playground sample): https://play.rust-lang.org/?version=stable&mode=debug&editio...

... which does put both cars and bicycles in the same queue, but doesn't eliminate the copy-paste for each new type completely; 'car' and 'bicycle' still wind up with separate 'get_speed' impls, which are textually identical aside from the type names.

Usually the way people solve this in Rust is with macros.

Re: Inheritance was invented as a performance hack

#192

Post by take3 » Fri, Apr 30, 2021, 1:57 PM UTC

whywhywhywhy wrote: post #190

take3 wrote: post #158

Earlier quoted context omitted.

If you're "not able to spend it in a lifetime..." Then you're selfish and no good for the money anyway. One can only buy so many jets and sports teams, sure. But, if society endows you with that sort of reward, it becomes your responsibility to move society forward with that blessing. Anything less is exactly why we live in Trump world and not some sci-fi future we all imagined as kids.

Life is more than just self indulgences, I don't actually see a point in working or contributing to society at all if I can't build a foundation that will benefit my children. I'm certainly not working so I can drive a fancy car or whatever. Honestly not sure I'd even bother getting out of bed most days if the future of my children was just in the hands of the state, what would be the point.

Sounds like you may be depressed. My mom would tell us of how, similarly, us kids would be the only thing that helped her get through periods of depression.

Life itself, even for those of us without children, is an incredible experience.

Re: Inheritance was invented as a performance hack

#193

Post by [deleted] » Fri, Apr 30, 2021, 2:02 PM UTC

slver wrote: post #171

Inheritance is static composition. Everything we do statically is for two reasons: 1. Static invariants (not subject to runtime-defined conditions). 2. Performance (AOT compilers know more about the system and can elide more code and devirtualize more calls, etc.). I think the characterization of performance features as a "hack" is misleading. The article builds a bit of strawman, being dismissive of a performance fe…

[deleted]

Re: Inheritance was invented as a performance hack

#194

Post by rectang » Fri, Apr 30, 2021, 2:07 PM UTC

dang wrote: post #57

rectang wrote: post #4

Fine. But obviously it caught on for other reasons, like code reuse and an intuitive mental model. The HN appetite for posts ragging on inheritance will never be sated.

" 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 semantically compelling.

Re: Inheritance was invented as a performance hack

#195

Post by sanderjd » Fri, Apr 30, 2021, 2:08 PM UTC

adrianmsmith wrote: post #157

ptato wrote: post #153

Earlier quoted context omitted.

Would that copy-paste code ever amount to more than some getter methods, like the get_speed() example you provided? If the speed field had some special behaviour, couldn't you wrap it in its own Speed type, with its own methods, and use that from the enclosing types?

I think the solution you've proposed is probably how you'd do it - but isn't inheritance more elegant in this case (i.e. using a language which supports inheritance if this is important to you)

No, inheritance is not an elegant way to mix in shared data and behavior. It can seem like it is in a simple case where there is only one set of data and behavior you want to mix in, but it scales very poorly. Nothing is fundamentally a single kind of thing, and multiple inheritance is a mess. It is more elegant to mix the behavior in through delegation, because it scales to however many things you want to mix in. Carrying on the synthetic example in this thread, you can mix in Speed and Pedals into Bicycle but Speed and Cylinders into Car.

Re: Inheritance was invented as a performance hack

#196

Post by tsimionescu » Fri, Apr 30, 2021, 2:08 PM UTC

tarkin2 wrote: post #188

Inheritance in the OOP sense can be simply implemented in most languages without OOP. In Javascript: var o1 = { a: 1, b: 2, c: 3 } var o2 = { x: 1, y: 2, z: 3 } o1 = Object.assign(o1, o2) o1.z // 3 o1 has now inherited o2. I don't see much difference between this and classic untyped OOP. Edit: copying functions over, not values, is what I’m getting at. Values used for simplicity of example

While it's true that it's easy to implement inheritance in dynamic languages, it's not quite this easy. The most important feature of inheritance is the function override support / virtual dispatch, so that o1.foo() and o2.foo() can do different things, but o2.foo() can also access o1.foo() (by using something like super.foo() in Java or BaseClass::foo() in C++). Ideally this would also be optimized so that each object doesn't have to carry a function pointer for each member function (this is why virtual function tables are generally used).

Re: Inheritance was invented as a performance hack

#197

Post by trgn » Fri, Apr 30, 2021, 2:12 PM UTC

tarkin2 wrote: post #188

Inheritance in the OOP sense can be simply implemented in most languages without OOP. In Javascript: var o1 = { a: 1, b: 2, c: 3 } var o2 = { x: 1, y: 2, z: 3 } o1 = Object.assign(o1, o2) o1.z // 3 o1 has now inherited o2. I don't see much difference between this and classic untyped OOP. Edit: copying functions over, not values, is what I’m getting at. Values used for simplicity of example

This work-around copies the values (in your examples), or the references (if the props are functions or objects), which is just wasted cycles and memory bloat. It's harder for runtimes to optimize, because with that mixin `o1` changes its shape. It's harders for IDEs to infer the type of `o1`, which will hurt navigating and searching through your codebase with confidence.

Implementing OOP in JS with hacks like this is worse, in pretty much all ways, apart from the intellectual kick many devs get of avoiding OOP at all cost, as opposed to just using built-in language features.

Re: Inheritance was invented as a performance hack

#198

Post by leshow » Fri, Apr 30, 2021, 2:15 PM UTC

SMFloris wrote: post #122

qalmakka wrote: post #101

In my experience, 90% of the time people use inheritance but they really only cared about composition, and their language simply does not have any convenient facility to compose types and re-export their methods. With a good type system that includes traits, you almost never need virtual dispatching, as any Rust developer may tell.

Recently experimented a bit with Rust and I found the reverse to be true. You cannot compose types in Rust. You compose behaviors not types. Very important distinction as I found out the hard way. Take the following example I have found on the net: https://play.rust-lang.org/?version=stable&mode=debug&editio... In that example, both the bicycle and the car have the property `speed`. Imagine you have multiple types no…

Monomorphization is not a user action of copy pasting, it's something the compiler does with parametric code. If we're talking about Rust it means when you write:

    fn id(t: T) { }

    fn main() {
       id(String::from("foo"));
       id(1_usize);
    }

The Rust compiler will generate a method of `id` that works for both String and usize, so there will be two copies of the function with a slight variation in your binary. That process is called monomorphization.

> Which was exactly what I was experimenting with: A single queue worker that can handle different cases. Honestly, it made Rust almost not worth it for me. Sadly, I was too deep to turn back so I wound up doing the whole thing in Rust. I have tons of copy-paste code. It is ugly and it is bothering me.

You can easily use generics, there is no reason to copy paste code like this

Re: Inheritance was invented as a performance hack

#199

Post by slver » Fri, Apr 30, 2021, 2:17 PM UTC

CuriouslyC wrote: post #177

slver wrote: post #171

Inheritance is static composition. Everything we do statically is for two reasons: 1. Static invariants (not subject to runtime-defined conditions). 2. Performance (AOT compilers know more about the system and can elide more code and devirtualize more calls, etc.). I think the characterization of performance features as a "hack" is misleading. The article builds a bit of strawman, being dismissive of a performance fe…

I frequently hear people malign inheritance, and while it can obfuscate code in some circumstances, it can also produce code that is easily and clearly extendable. For example, a class with a static method that uses class properties to control behavior is cleaner than a function factory that takes a config object. Interface inheritance is also quite useful.

I think thanks to Java opting to use "implements" for interfaces, people no longer associate "inheritance" as the thing we do when we write a fully abstract class (i.e. interface) and then "inherit" this abstraction to implement it. Interfaces are, of course, crucial.

Not sure I understood your example about the static class vs. function factory tbh though.

Re: Inheritance was invented as a performance hack

#200

Post by d1plo1d » Fri, Apr 30, 2021, 2:30 PM UTC

qalmakka wrote: post #101

In my experience, 90% of the time people use inheritance but they really only cared about composition, and their language simply does not have any convenient facility to compose types and re-export their methods. With a good type system that includes traits, you almost never need virtual dispatching, as any Rust developer may tell.

Very true. I'm checks cloc 14,000 lines into a personal project and I have yet to feel any need to use `dyn` (virtual dispatching for non-Rust folks).