If Inheritance is so bad, why does everyone use it?
If Inheritance is so bad, why does everyone use it?
Alloy Workshop There are still two slots available for the alloy workshop! I've been hard at work adding a bunch of teaching innovations to the class, which...
This essay says that inheritance is harmful and if possible you should "ban inheritance completely". You see these arguments a lot, as well as things like "prefer composition to inheritance". A lot of these arguments argue that in practice inheritance has problems. But they don't preclude inheritance working in another context, maybe with a better language syntax. And it doesn't explain why inheritance became so popular in the first place. I want to explore what's fundamentally challenging about inheritance and why we all use it anyway.
🙄 people who blindly say "inheritance is bad" or "composition over inheritance" and mean "no inheritance" are just like followers of religion. Always repeating the same stuff without thinking and being completely convinced they are right. Nigh everything has a place and a valid usecase and just because you don't see it doesn't mean nobody else does.
Edit: Also "sum types" and "algebraic data types" are horrible names. Pretty much the equivalent of "imaginary numbers". What the fuck is a "sum type"? How do you "add" types together? Adding numbers makes sense, it has a real world equivalent. Two balls in a cup, add one ball and you have three balls in a cup. Add color to water and you have colored water. Simple. But types? The fuck?
str | intis a sum type --> does that mean sum types are adding two spaces of possibilities together aka a union of two sets? The wikipedia article is so friggin bad at explaining it to people who aren't in the know.@onlinepersona @armchair_progamer
A type has a number of 'inhabitants'. 'Sum' indeed corresponds to adding the possible inhabitants together.
A Boolean has two inhabitants - true and false. A byte has 256 inhabitants. A BoolOrByte type has 258 inhabitants.
If you have BoolByte pair, that's a product type - 512 possible inhabitants.
It may make no fucking sense depending on your exposure to Java, where Void (literally 'empty') has an inhabitant, and Boolean has 5.
OK, that explains
bool | byte, but how is an enum a sum type? And what's a product type? A product of sets is a cartesian product. How does that work with types?
just like followers of religion
We say that shit, because we've touched code that's deeply inherited, and it was a god-damn pain to work with, because changing a single line can mean you'll need to update a fuckton more, which breaks tests all god-damn over, which means you may have to refactor 50% of the application in one go.
Anyway, everything has its uses (even goto). It's just there are typically better alternatives.
“sum types” and “algebraic data types” are horrible names.
Agreed, but they exist due to historic reasons, and now we're stuck with them. Not much we can do there ¯\_(ツ)_/¯
Pretty much the equivalent of “imaginary numbers”.
Terrible name that just means "vertical number line" (with an added operation where you rotate the vector, instead of add or scale), or "y-axis for the number line". It's funny because "Real" numbers are about as real as "Imaginary" numbers. Both are virtual (not physically existing).
str | intis a sum typeIt just means that the variable can either be a
stror anint. You've seen|used as "bitwise or", right? Think in that direction.PS: Stay away from Monads - they'll give you an aneurysm. 😂
In some langs like Python,
|is also the "union" operator, to join sets and such, which I think is more directly related to types, since types are sets of possible values.
The sum and product types follow pretty much the same algebraic laws as natural numbers if you take isomorphism as equality.
Also class inheritance allows adding behaviour to existing classes, so it's essentially a solution to the expression problem.
Yes, I know some of those words. Could you repeat that for those that aren't mathematicians or in the know?
Mathematically, the union of disjoint sets is often called the sum. This is a natural name because when you look at the number of elements (or in general, any measure), it will be the actual numeric sum.
Why the emphasis on "disjoint"? Aren't integers a subset of floats? Would that mean then that
int | floatis incorrect?
Saying "X is bad" or "Y over X" is not the same as saying "there is never a place for X". I think JS is a pretty bad language, and prefer other languages to it, but I still recognise very obvious places where it should be used.
Maybe it depends on the way you understand types, but to me sum and product types are completely intuitive. A type is a set of possible values. A sum type is multiple sets added together (summed).
Saying “X is bad” or “Y over X” is not the same as saying “there is never a place for X”.
That rarely comes across online where opinions are often stated dichotomously. Especially when speaking of inheritance, some crowds (I've noticed this in the Rust crowd) are vehemently against it and will do nigh anything not to think of a problem as one of inheritance nor a solution that could benefit from inheritance. The makers of the servo browser engine which has to implement hierarchical structures (the DOM) ran against this exact issue within the Rust community where inheritance might as well equate to blasphemy.
I recognise that it's probably a loud, zealous minority, but it makes interacting with the rest of the community rather difficult.
A type is a set of possible values. A sum type is multiple sets added together (summed).
That makes sense for
str | int, but how is an enum a "sum type"?As for product types, in set theory a product of sets is a cartesian product. How is a
struct Dog { height: u8 length: u8, name: String, } impl Dog { fn bark() { println!("woof!"); } }a product? What is it a product of? And why is the type itself a product, not
Dog x Cat? Or isDog x Catindeed some kind of product that I'm not aware of but with another syntax?
Obviously, it's not absolutely bad. I think the reason why it became very popular was because it allows you to reuse and extend functionality that already exists. This gives you a higher development velocity, which is obviously something that companies prioritize, and developers want to provide.
Right, that's the third meaning he cites for inheritance.
Was half asleep when I wrote this lol
It does frustrate me that people say "composition over inheritance" and then act like the problem is solved.
For a start, dependency injection is an abomination. Possibly the single worst programming paradigm in the history of software development.
The only codebases I've seen that deliver on some of the promises of composition have been entity-component systems, but this concept hasn't even matured to the point of being a first-class language construct yet, so the programming style is pretty janky and verbose.
dependency injection is an abomination
I don’t think so, dependency injection has made testing easier in all static typed code bases I worked on.
The general idea is to not test things that need to be mocked, keep all logic out of those and keep them at the edges of the application. Then you test the remaining 90% of your code which would ideally be pure functions that don't need mocks .
The remaining 5% can be integration tests which doesn't care about DI.
In reality this doesn't always work, because sometimes it's better to write a complex query with logic and let your database do the processing.
How does DI make testing easier, or the lack of it make it harder?
Having a framework scan your code tree for magic annotation and configurations, etc, in order to instantiate "beans" or what not, is the worst imaginable tradeoff I've ever seen in software development. Calling it an abomination sounds exactly right.
Inheritance isn't bad. Those people are dumb.