Inheritance was invented as a performance hack • Hacker News Board

Re: Inheritance was invented as a performance hack

#181

Post by ptato » Fri, Apr 30, 2021, 1:19 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)

Maybe not on every situation, but I do agree that inheritance is more elegant in a lot of situations, in the sense that it gets some behaviour "out of the way".

Re: Inheritance was invented as a performance hack

#182

Post by throwaway894345 » Fri, Apr 30, 2021, 1:20 PM UTC

username90 wrote: post #54

throwaway894345 wrote: post #52

Earlier quoted context omitted.

I don’t think it’s true that reuse means tight coupling. With composition you can swap out the composed object at runtime and as far as compile time coupling is concerned you can embed an interface to decouple the outer object from the inner object.

All code reuse creates coupling on some level. Creating more abstractions in between reduces coupling but creates code bloat. There is a trade off. For example, if you call the same function from many locations those locations are now coupled since if you change the function you change all of those locations behaviour. Many times that is desirable, in which case it is good coupling. The exact same rule applies to inh…

Can you elaborate a bit? How is there coupling between a thing which uses an interface and a thing which implements the interface of the two don’t know about each other? Especially if the interface is implicit à la Go interfaces or structural subtyping?

Re: Inheritance was invented as a performance hack

#183

Post by mumblemumble » Fri, Apr 30, 2021, 1:30 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.

> it can also produce code that is easily and clearly extendable

It can also produce code that is not easily and clearly extendable, if the behavior you're trying to extend is buried a layer or two further down the inheritance hierarchy.

Unfortunately, due to the First Law of Kipple, the rate at which you run into this problem is proportional to the age of the code base. And so we grow frustrated with implementation inheritance. Other extensibility mechanisms probably have similar pitfalls, but they haven't been the dominant way of doing things for long enough to accumulate the same volume of clutter.

Don Knuth has mentioned in a few interviews that he isn't so hot on code reuse, and prefers code that's designed to be easy to edit over code that's designed to be easy to extend. I'm starting to see some wisdom in that idea. With the one, being able to keep things tidy is a primary goal. With the other, eventually tidying becomes a frightening enterprise, because you have to avoid upsetting the inheritance hierarchies that are precariously balanced on top of the code you're trying to tidy up.

Re: Inheritance was invented as a performance hack

#184

Post by rst » Fri, Apr 30, 2021, 1:37 PM UTC

dwattttt wrote: post #143

SMFloris wrote: post #122

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

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.

Re: Inheritance was invented as a performance hack

#185

Post by KineticLensman » Fri, Apr 30, 2021, 1:37 PM UTC

fiddlerwoaroof wrote: post #9

I think discussions of OOP and inheritance often miss the influence of Knowledge Representation on OOP: I’m not entirely clear of the history myself, but I’ve gotten the impression that knowledge representation research (things like frame systems) was a semi-independent influence on the design of OO systems

> I’ve gotten the impression that knowledge representation research (things like frame systems) was a semi-independent influence on the design of OO systems.

Definitely! See [0]. Personally, I came across Frame-based knowledge representations in the mid-1980. For reasons that were frankly insane, I was trying to code a frame-based knowledge representation in distinctly non-OO K&R C as part of a collaborative university research project. I moved into industry in 1988 and used OO for the first time (the Common Lisp Object System) and finally started with C++ in around 1993. Obviously this was my personal career trajectory but I encountered knowledge representation research before mainstream OO languages.

[0] https://en.wikipedia.org/wiki/Frame_(artificial_intelligence...

Re: Inheritance was invented as a performance hack

#186

Post by Shorel » Fri, Apr 30, 2021, 1:37 PM UTC

anonytrary wrote: post #80

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. ;)

I was thinking the same thing.

Re: Inheritance was invented as a performance hack

#187

Post by CuriouslyC » Fri, Apr 30, 2021, 1:41 PM UTC

mumblemumble wrote: post #183

CuriouslyC wrote: post #177

Earlier quoted context omitted.

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.

> it can also produce code that is easily and clearly extendable It can also produce code that is not easily and clearly extendable, if the behavior you're trying to extend is buried a layer or two further down the inheritance hierarchy. Unfortunately, due to the First Law of Kipple, the rate at which you run into this problem is proportional to the age of the code base. And so we grow frustrated with implementation…

I think the practice of not using a tool because people could potentially misuse it is misguided in this day and age. Linting and static code analysis are quite capable of enforcing good usage patterns.

Re: Inheritance was invented as a performance hack

#188

Post by tarkin2 » Fri, Apr 30, 2021, 1:41 PM UTC

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

Re: Inheritance was invented as a performance hack

#189

Post by Thursday032521 » Fri, Apr 30, 2021, 1:42 PM UTC

dahfizz wrote: post #161

bb101 wrote: 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.

Correct- it should go to the workers.

Re: Inheritance was invented as a performance hack

#190

Post by whywhywhywhy » Fri, Apr 30, 2021, 1:52 PM UTC

take3 wrote: post #158

dudeinjapan wrote: post #85

Earlier 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

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.