Live data from Hacker News

Inheritance was invented as a performance hack

catern.com

251–260 of 268 posts

Re: Inheritance was invented as a performance hack

#251
post #219

Earlier quoted context omitted.

> Honestly I've not seen such a strong characterization of inheritance as being purely semantic. As articulated elsewhere in the discussion, classical inheritance has a great affinity for the "specialization" design pattern, which is everywhere. Classical inheritance is not just a performance hack, it is semantically compelling , as illustrated by the enduring popularity of "Cat Extends Animal"! Furthermore, single i…

> Classical inheritance is not just a performance hack, it is semantically compelling I think often it's compelling for misleading reasons. For example, is a square a rectangle? Mathematically, yes. But in mathematics, we don't mutate values (we would describe an entity's evolution as a series of values). If you are allowed to mutate the dimensions of a rectangle object, then for a square to be a rectangle, it must s…

That's cleared up by understanding covariance and contravariance and the fact that mutability is an attribute.

Re: Inheritance was invented as a performance hack

#252
post #154

Earlier quoted context omitted.

Your business doesn't operate in a vacuum. It is licensed and supported by society. The same society that benefits from inheritance redistribution.

By that logic, why let the business owner make any money at all? It's really society's business after all.

No need to make a dichotomy out of a spectrum. Business owners pay some tax and receive some profit - we need only adjust the relative percentages.

Re: Inheritance was invented as a performance hack

#253
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'm sure you mixed that up.

Inheritance is the dynamic variant of composition.

You can dynamically extend objects by adding fields and methods to it's class, but not to composed objects, because they are statically closed. (Well in the good languages. javascript and friends still allow to extend objects, to violate their types).

You can also dynamically mess with the inheritance search path, or fall into the diamond trap. Not with static (or maybe call it lexical) composition.

Composition wastes a lot of space and disallows dynamic extensions, like plugin overrides, test mocking, ... But is very good with proper structural typing, and is a good performance hack, because it doesn't need to chase pointers at runtime, and neither do the inheritance search and linearization dance.

Re: Inheritance was invented as a performance hack

#254
post #247

Earlier quoted context omitted.

Nothing will magically start calling your new function. If you are defining a new function that didn't exist before, then you'll have to actively call it somewhere. What you're describing instead is overriding an inherited function. However, that is full of pitfalls, I would not call that "for free" by any means. There are example of the problems in this very thread. Anyway, that's distinct from polymorphsim, which i…

But that's what polymorphism does. Somewhere deep in the code is calling a.foo(), but when you pass a subclass of A that overrides foo(), then this code "magically" calls that new implementation. This is where specialization shines and no other paradigm allows this so elegantly and so simply.

That is not exclusive to OO and it wasn't invented by OO either. However, the common pitfall of changing the implementation of a method that was not designed to be changed I would argue to be more common in OO than in other paradigms. That's a common pitfall, though. Not a place where OO shines. Though, to be fair, that's a problem in Java, Python and other popular OO languages, but not inherently a problem of the paradigm per se. C++, for instance, avoids that common issue by not making methods virtual by default.

Re: Inheritance was invented as a performance hack

#255
post #68

Earlier quoted context omitted.

It turned write-only before the Eternal September of wikispam set in

I am trying to start a wiki project and I have no idea what sort of world of stupidity I’m about to step in to, do I? I had thought of building the history system on top of a theory of patches system would be a nice stretch goal. But it seems to me that having an infinite undo function drastically changes the account creation situation. I only have to be passingly sure you’re not a bot, and I can decide after the fac…

You should consider event sourcing for all given information. Then, you can undo/redo as much as you wish.

Re: Inheritance was invented as a performance hack

#256

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

Seems to me to be very different from the OO concept of inheritance: You're copying values between variables, instances of a type. The OO idea is about the type definition; it affects all instances of a type without any per-instance boilerplate code at all.

Re: Inheritance was invented as a performance hack

#257
post #197

Earlier quoted context omitted.

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 i…

I agree copying values is not massively smart. (Used for simplicity of example) But copying function pointers seems negligible. I can’t see this being avoided even in traditional oops.

The whole point of "traditional OOPS" is to avoid per-instance boilerplate code.

Re: Inheritance was invented as a performance hack

#258

Pretty off topic comment, but I read the title as "inheriting money is a way avoid being a high performer", which happens to be true, although completely irrelevant to the actual article. ;)

Exactly how I read the headline on the front page too. In fact, I clicked through to this page mainly out of curiosity as to which meaning was the intended.

Re: Inheritance was invented as a performance hack

#259

After 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…

Seems like just a buggy implementation to me. You can make buggy implementations of any concept; if that invalidated the concept itself, there would be no valid concepts at all.

Re: Inheritance was invented as a performance hack

#260

Earlier quoted context omitted.

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…

It's also an extension of basic property rights. An owner of property may will it to whomever he pleases on the event of his passing. It's no different from simply gifting property while alive.

Most discussions of inheritance tax (perhaps particularly discussions where US Americans are involved?) seem to start from this perspective, "the deceased person is being taxed". I find that a little weird. All these weird objections go away like a puff of smoke if you see inheritance tax the other way around: It's a tax on the recipient of the inheritance. Why shouldn't inheritance (or gift!) income be taxed, when any other income can be?
Post reply on HN