Inheritance was invented as a performance hack
141–150 of 268 posts
Re: Inheritance was invented as a performance hack
#142After 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…
> This problem is impossible to fix and it is a general problem - when overwriting a method, you can never be sure that semantics could break when the base class is changed. I'm not sure what's so special about overwriting methods here. There are many cases where semantics can break as a dependency changes. One example would be whether a callback is executed on the same thread (or event-loop tick) or in the backgroun…
The problem with implementation inheritance specifically is that there is no single responsibility for establishing this semantics. Every method call on overridable methods incurs a dispatch step involving the whole of an arbitrarily extensible inheritance hierarchy, and every method can be called by an unknown extent of user code. You just can't give a proper semantics to it without looking at the whole-program level, which is antithetical to modularity.
Re: Inheritance was invented as a performance hack
#143In 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…
Re: Inheritance was invented as a performance hack
#144Earlier quoted context omitted.
Yes, I mean java.util.LinkedList. Obviously, one can do manual writing of Java (or even use m4 macros or hijack the C preprocessor... the preprocessor doesn't know anything about C beyond tokenization) for anything C++ templates can do. It's just tedious and potentially error-prone. Here's hoping Java eventually gets reified generics.
> can do manual writing of Java (or even use m4 macros or hijack the C preprocessor... the preprocessor doesn't know anything about C beyond tokenization) for anything C++ templates can do Sounds broadly true, but I'm not sure it's precisely right. How could std::is_same be implemented?
You would perform manual static context-sensitive text expansion, just like the C++ template expander does. In this case, you end up just manually expanding it all the way out to a true or false by hand.
I'm just saying that the C++ template expander only performs static context-sensitive text replacements, ending in valid template-free C++ code. The template engine doesn't introduce any magic that can't be done more tediously in template-free C++ by hand, so you can do the same tricks in Java by hand.
Now, Java doesn't have non-primitive value types, so you'd have to manually flatten some classes in order to get the same layout without the class boundary forcing an indirection. Java also doesn't allow interior references while C++ absolutely does, but that's outside the C++ template expander / template sub-language.
Re: Inheritance was invented as a performance hack
#145Earlier quoted context omitted.
Ted Kazinsky was talking about it in his manifesto. https://unabombermanifesto.com/#THE%20POWER%20PROCESS It depends on how much you provide for your offspring according to this deranged terrorist. And I've read stories from billionaire kids not living "the good life" because they never have to fight/work for anything.
That's just bad parenting. I think rich people tend to be people obsessed with work, giving access to money is easier than teaching their kids to earn stuff - it is a different problem.
Re: Inheritance was invented as a performance hack
#146Earlier quoted context omitted.
What's wrong with someone wanting to provide for his offspring?
Ted Kazinsky was talking about it in his manifesto. https://unabombermanifesto.com/#THE%20POWER%20PROCESS It depends on how much you provide for your offspring according to this deranged terrorist. And I've read stories from billionaire kids not living "the good life" because they never have to fight/work for anything.
Re: Inheritance was invented as a performance hack
#147Earlier quoted context omitted.
> "inheriting money is a way avoid being a high performer", which happens to be true By what metric? Or do you mean "a way to avoid having to be a high performer in order to achieve good results"? Isn't the whole beef with wealth inequality that given otherwise equal luck and faculties, a person who starts with more capital will gain more capital?
The two aren’t mutually exclusive. The children of the very wealthy often (usually?) share their parents’ economic advantage, thus perpetuating the inequality that originated due to economic factors. But that doesn’t mean they’re driven or that they’ll develop the same qualities that drove their parents to be successful.
That's the point: a leasurely trust-fund baby will likely be more "successful" than a hardworking and "driven" poor person.
Re: Inheritance was invented as a performance hack
#148Earlier quoted context omitted.
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…
I've heard "monomorphisation" to refer to something a compiler does, but not something a programmer does. I think this is just "repetition"! The need for something to solve the problems inheritance solves has been known in Rust for a long time. Mostly it's been motivated by the need to implement the HTML DOM, which is fundamentally an inheritance hierarchy, in Servo. There's a longstanding RFC about it: https://githu…
Another issue I have with it is perfectly described in this article: https://theta.eu.org/2021/03/08/async-rust-2.html
Re: Inheritance was invented as a performance hack
#149Earlier quoted context omitted.
I read it similarly as "inheriting money". And it's true that inheritance IS a performance hack--not for the children, but for the parents. Inheritance incentivizes parents to accumulate wealth not just for one lifetime but for multiple lifetimes. (Granted it may paradoxically have the opposite effect on the children as you mention.) Here's Milton Friedman on the matter: https://www.youtube.com/watch?v=km9OCw3f5w4
Inheritance is a natural phenomenon. If all my money were stolen when I die (let's say, 100% inheritance tax), I wouldn't have much incentive to grow my business more once my business makes more money than I can possibly spend in a lifetime. Sure, some people may still do it because they love working or because they love providing for their society. The main reason I want to accumulate money, is so I can offer them a…
>going through the corporate bullcrap I had to do when needing some starting capital.
The corporate bullcrap you had to go through is a direct consequence of someone growing their business beyond what they could spend in a lifetime.
Re: Inheritance was invented as a performance hack
#150In 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…