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 say it's never the right tool or, conversely, always the right tool makes you sound ignorant and inexperienced.
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) while a detractor doesn't like how it forces each subclass to carry along the baggage of its superclass (implementation inheritance). These people are not going to have a fruitful discussion without understanding that they're talking about different things.
The concept of "types" in programming languages is another great example -- there are syntactic type declarations, memory-level types to specify which bytes mean what, things like typeclasses or interfaces which give you runtime polymorphism, the "type" you have in your head when you're thinking about what kind of data your code needs to handle... before you even start to have a discussion, you need some idea of what you're talking about.
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? :-)
> or you disallow ontological inheritance completely (like Golang, and therefore cannot support many modern programming features
Sincerely, what features does this preclude. I pretty much ignore ontological inheritance in any programming language because it never seems useful. Am I missing something?
> 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 customary conceptual understanding of inheritance within software engineering, and whether this understanding "makes sense".
This is an easy enough mistake to make simply from reading the title, but one that should have been cleared up in a matter of seconds once you started reading the article body, which I presume you did, rather than immediately rushing to the comment section?
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.
Agree. Tools are only as good and effective as those who use them. At some point we have to be responsible for the decisions we make. And sometimes biz needs change to the point that those decision change from right to wrong. Just me?
I hear the author. Just the same, at 50k ft, it just seems like the same subject on a different topic. That subject is: Peogramming / software engineering is imperfect. And sometimes things break and need to be refactored.
Why should this profession be any different than any other. The quest for The Holy Grail of Perfection is nobel, but we'll never find it.
I'm not suggesting sloppiness and lower standards, but a sense of theory is great but the reality is reality will never be that perfect.
Use the right tool available at the time. When that tool is no longer right and/or effective then replace it. Keep moving.
We haven't been given an expiration date regarding ignorance and inexperience so it's no surprise we see it in 2018 or that we will continue to see it well into the future. An interesting question is whether the amount remains relatively the same or there's some "evolutional" trend, but this seems very hard to both quantify and qualify.
>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.
Even more so if you're arguing against a strawman position never even mentioned in the article...
"Why inheritance never made any sense" in the title is meant as: "here's why people are often confused by inheritance, and here's a better way to think about it".
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 say it's never the right tool or, conversely, always the right tool makes you sound ignorant and inexperienced.