Oh, come on. The title submitted to HN is "Inheritance often doesn't make sense"; the actual title of the article is "Why inheritance never made any sense". Are you kidding me? Do we really need, in 2018, another article continuing this particular religious war? Inheritance is just another tool in the software engineer's toolkit. When you need that tool, use it; when you don't, don't. But taking a position where you…
It's hard to tell whether you didn't read the article, or you read it but were so preoccupied with an existing train of thought that you essentially responded to an imagined version of it. I would generally agree with your point if it was about one of the many articles that do try and make this point but I don't see where this one does.
Oh, come on. The title submitted to HN is "Inheritance often doesn't make sense"; the actual title of the article is "Why inheritance never made any sense". Are you kidding me? Do we really need, in 2018, another article continuing this particular religious war? Inheritance is just another tool in the software engineer's toolkit. When you need that tool, use it; when you don't, don't. But taking a position where you…
I didn't get that from the article at all. I actually like what the article is doing a lot, and I wish people would take the same approach more often. When arguments about high-level concepts like inheritance go poorly, it's usually because everyone involved is talking about something slightly different. Maybe a supporter of inheritance likes the way it lets them think about their program (ontological inheritance) wh…
The problem balancing implementation vs ontological inheritance while providing strong type safety is that your language needs to either support defining contravariant types (and you still likely end in a mess, see Scala's eternal discussion about "total" type safety), or you disallow ontological inheritance completely (like Golang, and therefore cannot support many modern programming features, for the better or worse, doesn't matter). Not sure if there is a language that truly does the opposite by design, though (being strongly typed and disallowing implementation inheritance, while providing ontological inheritance). Such a language might be the DDD modeller's heaven? :-)
> you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height) Can someone come up with a better example here? Intuitively, I would say, "Yes, if you ask me for any rectangle, and you reject a square, you are wrong." If you say you can use any rectangle to do your thing, you should absolutely be able to also use a square. Why am I not convinced with the give…
> and you can't just will it to have a different width and height and expect it to obey you through some force of nature I think you have let functional programming and immutable data-structures bias your world view. The real world is mutable and the wonder of the digital mutable world is that it is pretty much just will-alone that can set attributes as you describe. It is immutability that is a trendy but artificial…
I used to feel like this before writing big and complex programs. But in term of practicality, it's a whole lot easier to just write the expansion of "rectangle" to "square" than re-writing "square" from scratch, essentially copying the majority of "rectangle" properties and functionality.
> But taking a position where you say it's never the right tool or, conversely, always the right tool makes you sound ignorant and inexperienced. Neither of those positions is advocated by the article, so who exactly are you talking about? In fact, you seem to have assumed that "make sense" in the title referred to the issue of whether or not to use inheritance, whereas in fact the article is concerned with the custo…
We don’t use inheritance anymore. If something needs to be shared it gets its own service class.
Every time we’ve used inheritance it’s ended up being more of a hassle to keep track of as functionality changed. I know we could utilize it better than we have, but that’s part of development management as I see it, if I know my crew won’t utilize something to good effect, then it’s often better to adapt our practices rather than fail at change management after a long period of trying. Especially because a lot of new hires are really bad at OO principles beyond the fundamentals.
I don't understand why some functional programmers have so much difficulty with the concept of inheritance. Discriminated Unions and pattern matching is just inheritance and virtual dispatch turned inside out. Yet no one is naval gazing about whether their algebraic datatypes are 'ontological' or not. I also really wish people wouldn't try and dismiss concepts they're ignorant of: because multiple inheritance is inco…
Actually, I think they are kind of duals to each other. With pattern matching it is easy to write new functions but hard to add a new case (you need to edit every previous pattern match you wrote). On the other band with classes it is easy to add a new class but hard to add a new method (you need to edit every single class you previously wrote that implements that interface)
Functional programmers call this the "expression problem"
I think inheritance make code more coupled, which make it hard to delete or refactor. Most of the cases it's better to just copy and paste. You can still share methods. But the moment you need to modify a shared method just so it can be reused: Make a new function instead. One popular solution is to only let functions do one thing but that leads to even more coupling and less reuse.
There's a fine balance between reuse and coupling. Where reuse is good and coupling is bad. A general rule for when to reuse/share/modularize is when the method/function can be reused in other code base. eg. when it can be/is decoupled.
This article seems to be confused about what abstract data type inheritance is, as exemplified by "As a type, this relationship is reversed: you can use a rectangle everywhere you can use a square (by having a rectangle with the same width and height), but you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height)." If an abstract data type X inherits from…
> That also means that you can't have mutable values, static types and subtyping in the same language Yes you can. You just need to make a clean separation between mutable variables and immutable variables. Then mutable variables must be invariant, and immutable variables can enjoy subtyping. Alternatively, classify mutable variables further and make references carry information about whether only reading/writing is…
Agreed, although I'd go a step further. A mutable variable has a type of reads and a type of writes. They vary in opposite directions. If you constrain them to be the same then they must therefore not vary at all.