Live data from Hacker News

Inheritance was invented as a performance hack

catern.com

151–160 of 268 posts

Re: Inheritance was invented as a performance hack

#151
post #144

Earlier quoted context omitted.

> 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?

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

C++ templates cannot be implemented purely by text replacement as most of it is type driven.

It is true that you can do anything that templates do by hand, but that's true for any language construct (at the limit you could write asm).

Re: Inheritance was invented as a performance hack

#152

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

Heh. Have we all been trained to expect increasingly medium-style lifestyle content on HN ? This title was a nice Rorschach test.

Re: Inheritance was invented as a performance hack

#153

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…

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?

Re: Inheritance was invented as a performance hack

#154

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

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…

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

Re: Inheritance was invented as a performance hack

#155

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

Monetary inheritance is likely bad for the species from an evolutionary standpoint.

For example, if a "manipulative anti-social" gene was increased in prevalence because it maximized net worth.

The problem here is a common issue in game theory, optimization without regard for process. Your inheritance doesn't care how it was acquired.

Sure this could be offset for positive genes, but that's making one big assumption.

The assumption that capitalism is the only reward function for our species. That is, what other forms of inheritance reproductively compete with money?

Re: Inheritance was invented as a performance hack

#156
post #29
post #26

Earlier quoted context omitted.

c2 has some interesting thoughts on the topic. https://wiki.c2.com/?KnowledgeRepresentations https://wiki.c2.com/?TypeInferenceStory https://www.cin.ufpe.br/~mtcfa/files/in1122/Knowledge%20Repr...

How is it that c2 has remained so quality?

It didnt? there is a _lot_ of "no u" arguments on C2

Re: Inheritance was invented as a performance hack

#157
post #153

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…

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)

Re: Inheritance was invented as a performance hack

#158

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

Re: Inheritance was invented as a performance hack

#160
post #135
post #127

Earlier quoted context omitted.

> A Java-like linked list means an extra level of indirection I guess you mean java.util.LinkedList that has virtually no use case that's not outperformed (both space and time) by another datastructure. Writing your own linked list with prev(+next) pointers ain't hard by it's nothing like C++ templates. The removal of layer of indirection does work in Java [pretty well] as well - like extending AtomicReference (or At…

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.

Obviously you can do

public class Node{ Node prev, next; //stuff comes here .... }

Then extend and have the overall code that deals with modifying the datastructure, but it's overall ugly. Personally I have written enough datastructures where linking nodes is useful. For example: red/black tree + insert order 'next' makes for a decent implementation of a moving median. Yet, that's not what almost any developer would do normally.

Post reply on HN