The key is "prefer composition to inheritance" and dates back to Gang of Four.<p>The word "prefer" is critical to understand. It just means "usually choose A over B" <i>not</i> "B is never the right answer."<p>Unfortunately, since we - as an industry - like hard and fast rules, we move towards that second explanation and act like inheritance never makes sense. Like any tool, there's a time and place where it is the best tool, other times where it's a reasonable tool, and other times it's a terrible tool.<p>Therefore "everyone uses it" because either a) it's a reasonable approach or b) the developer doesn't know of or can't use a better one.<p>We should work on fixing b) instead of denying a) exists.
I feel people don't understand what inheritance and (object orientation in general) is useful for, misuse it, and then it gets a bad reputation. It's not about making nice hierarchies of Cars, Fruits, and Ovals.<p>For me the main point is (runtime) polymorphism. E.g. you have a function that takes a general type, and you can pass multiple specific types and it will do the right thing. And if you want to avoid huge if-else statements, you should put the code for the special cases in the classes, not in each function that operates on them.<p>You can get this without implementation inheritance, it is also possible to just have something like interfaces. But I do find it very convenient to put common code in a base class.
Nobody calls it this, but cascading styles in CSS is just like inheritance and I think should be avoided for all the same reasons. I feel it's a big part of why CSS at scale becomes unmaintainable. There isn't even a built-in way to compose two classes together if you want to avoid cascading/inheritance.<p>It looks like composition over inheritance has caught on as the better default in other languages, but in the CSS world people still cling to the cascade as a best practice for some reason.
Inheritance is a local maxima. When the hierarchy of classes to consider is small, it often “seems to fit”. It allows the programmer to progress quickly and with low effort as a lot of the code sharing behavior is provided by the inheritance mechanism.<p>Trouble often comes down the line. We keep adding classes, and soon we find that the hierarchy no longer is “shaped like a tree”. A soccer ball is a spherical object but also a sports equipment and a bouncing object, and there’s no way to organize those into branches.<p>Our reality isn’t “tree-like”, except when we simplify it extensively.
My impression is that inheritance is in many common programming languages the easiest way to share code. Sharing code in another way would require some more thoughts and sometimes code, so the lazy programmer takes inheritance.<p>Traits as a general concept would be very useful in many programming languages, but only some (like Scala) have proper support for it. In principle a Java interface with default methods (implemented methods) is also something like a trait, but very limited compared to traits in Scala. I have no statistics, but my impression is that inheritance is much less used in Scala, because the language has an easy to use alternative.<p>Another example is Go, where structs with their associated methods can be embedded, what is exactly composition supported by the language. Since Go doesn't support inheritance, programmers obviously needs to use this approach, so you would never see inheritance in Go programs.<p>So, my conclusion is that the usage of inheritance depends on what the language supports and how easy it is to use.
It seems like protocols solve 90% of the problems that inheritance does, but with 10% of the headaches. Instead of trying to ensure that two types can both be passed to a function that only knows about the parent type, just have a parameter that says "Whatever's passed has to conform to this, I don't care what it is otherwise."
There is no valid use case I've ever seen where inheritance was better than composition (that does not mean a use case does not exist, but evidence is mounting against it). I would say it's used because every language made a poor decision by building that in as the way to encapsulate reusable logic. i.e., a mistake.<p>Some APIs may expose themselves as requiring you extend a base class, and in that case you might as well do what the library author said. But overall? Yes, some things can work well with inheritance (eg. classical UI frameworks), but these are often equally good with a composition based API.<p>One job I was at I added a lint rule to flag `extends` as an error. You would need to add a comment to justify why you were using inheritance - it went over more favourably than I expected. I think I would suggest this for any new projects using a language that supports inheritance - discourage it with automation, but allow really good reasoning to prevail in review. It is the worse solution at least 99% of the time because it requires you predict a future that is painful to change.
The article has a nice history review of inheritance, but it would have been useful for there to be some concrete examples.<p>The worst example of inheritance I've ever found is in java Minecraft's mobs[0]. It is very deep in some places and has numerous examples of sub classes not fully implementing their parent interfaces.<p>Example 1: Donkey[1]<p>Donkey > Chested_Horse > Abstract Horse > Animal > Ageable Mob > Pathfinder Mob > Mob > Living Entity > Entity<p>Example 2: Blaze[2]<p>Blaze has a bit for 'Is on fire', but how is this any different from Mob 'Is aggressive'?
Blaze > Monster > Pathfinder Mob > Mob > Living Entity > Entity<p>[0] <a href="https://wiki.vg/Entity_metadata#Entity" rel="nofollow">https://wiki.vg/Entity_metadata#Entity</a><p>[1] <a href="https://wiki.vg/Entity_metadata#Donkey" rel="nofollow">https://wiki.vg/Entity_metadata#Donkey</a><p>[2] <a href="https://wiki.vg/Entity_metadata#Blaze" rel="nofollow">https://wiki.vg/Entity_metadata#Blaze</a>
Smalltalk having a more or less revolutionary developer experience was likely quite important. A graphical interface to your system where you can traverse a tree and inspect _everything_, and more importantly, change it.<p>In Smalltalks as I know them, which is sporadically and shallowly, inheritance seems to be used as a factoring tool, when you break down functions into smaller functions there's a structure in which to place them with the implicit incentive to put them as high up as possible.<p>To me it seems to work pretty well, but it's also a rather weird environment where even classes themselves are objects.<p>In Java one can get around inheritance by using injection into an attribute in a wrapper class that extends or changes an object API. This leads to a similar decoupling as more functional composition, but you pay by having more objects swimming around in the VM during execution. Extending on the class level (i.e. in declarations of classes, interfaces, traits and the like) instead of the object level might have effects on performance and resource management.<p>Usually that likely doesn't matter, but it might. In Java-like languages I tend to use inheritance as a quick way to abstract over or extend functionality in a library class, I get the public methods 'for free' in my own class without having to write the wrappers myself. And that's usually where I stop, one level of inheritance, since Java isn't as inspectable and moldable as, say, Pharo, and doesn't give the same runtime ergonomics with large class/object trees.
huh :o) the wisdom since late 90's has been to avoid it like a plague, at least in c++ circles. for example, see numerous articles in 'guru-of-the-week' by herb-sutter.<p>the same wisdom can be applied elsewhere as well, there is no need to keep discovering the same truths in different contexts again, and again.
I only tend to see inheritance in engines and libraries, where it makes sense to create more generic, reusable and composable code, since most of the functionality in these is defined by technical people.<p>It makes no sense to use inheritance in the business layer, because a single feature request can make a lot of the carefully crafted abstractions obsolete.
I stopped using inheritance when Swift protocols and TypeScript interfaces came along. Although it sometimes means you need to do nasty things with generics, it beats the fragility of inheritance. With ObjC, I eventually came to hate updating superclasses, because I knew it would lead to unexpected behavior in subclasses.
I don't think inheritance is bad at all. It is very often the easiest way by far to model a problem. Sure, it's not perfect, but I think it is wildly overhated by a vocal minority.
While I don't use the ecosystem, I like the way Go approaches it with interfaces by being minimal, expressive, and flexible. It something works like something else according to a minimal specification, it's the same. There's no sealing off things or top-down mandates that require changes to other people's code. Rust traits aren't exactly the same because they require changes to everyone's code to follow an exact model that cannot be retrofitted to existing code without additional work. One downside (it may not be the case today) with the Go model is requiring a type to fulfill one or more interfaces requires additional hoops such as no-op init() interface assertions.
It seems like there's a huge industry of people critiquing Java and OOP but misdiagnosing the problems as technical rather than sociological.<p>The immense pain and suffering that is related to Java and its ecosystem is because of the terrible organizational conditions that tend to co-occur with usage of Java. Big slow companies, long boring meetings, arguments about design patterns, "architects" who haven't written code in ten years, etc etc. Java correlates with, but does not <i>cause</i>, those conditions.<p>Another way of saying it: if Java was good enough for Nutch to use to write Minecraft, it's good enough for the vast majority of business purposes.
It’s only implementation inheritance that is questionable, and the reason is that it leads to mutual dependencies on implementation details between superclass and subclass. Reasoning about correctness becomes difficult, and the superclass is very constrained in what implementation details it can change without potentially breaking some subclass.<p>Bertrand Meyer’s open-closed principle can be read that way: The superclass is closed to modifications. But that goes against the principle of decoupling interface from implementation: The superclass interface is now stuck with the existing superclass implementation.
Here is my take on it.<p>At one point "Object Oriented" became "Blockchain" (or now Gen AI) of those times. You had to be "object oriented" in order to be taken seriously. This applied to everything. Even finished software products were called "built using object oriented".<p>The esoteric concept of inheritance became popular after that. At some point it became so popular that people figured out that it is not really a good thing.
In my mind, the more generic rule underneath these rules is you want to be able to comprehend what a unit is doing without jumping between a massive number or files or contexts. Inheritance hierarchies with shared state and overrides means you need to understand multiple files and their interactions vs interfaces and composition tend to allow for fairly understandable units with clear interactions.<p>The big problem these deep inheritance hierarchies cause is mediocre programmers often think they're writing good code (often high focus on maximal reuse) but the interfaces and clarity are terrible.
I prefer languages with full OOP, ideally with multiple dynamic dispatch. What I'm not fond of are languages like Java that overuse OOP design patterns, force you into them, or require lots of OOP boilerplate. If you have a class whose sole instance serves as a factory for other objects, you know you're on the wrong path. But I've never seen any coherent and sound arguments against OOP in general. Nobody forces you to use it, and, for example, it would be much easier to develop and deal with GUI frameworks in Go if it had classes with inheritance. As a rule of thumb, if for some reason your language drives you to emulate dynamic dispatch with explicit type switches on one or even multiple arguments, then it probably should have inheritance and dynamic method dispatch.
There’s a rule-of-thumb I’ve found about OOP where you want to use composition when extending data, and you want to use inheritance when extending behaviors.<p>The zoo animal metaphor that you often see used in teaching inheritance (lions are animals, simba is a lion all animals have a length, but lions also have claws etc.) is a bad perspective and you should never use inheritance to model a problem like that in the real world.<p>The only time I’ve used inheritance, has been on toy problems that didn’t need it. Not to say it doesn’t have its place but when I encounter it, it’s time consuming to peel back all the layers or deal with idioms that don’t quite fit a problem that a developer has enforced through inheritance.
Inheritance is really just a public interface, a private interface and automatic delegation of those interfaces to the base class.<p>The problems with inheritance are:<p>- people shove code in the base class to dedup it without thinking about design<p>- people add public and protected methods without thinking about interface design<p>- the names of the base class and the public and protected interfaces are exactly the same thing<p>The last point is that if you have a FooBase class which is public then you can wind up with a bunch of List<FooBase> containers that are coupled to the base class and external methods that take FooBase parameters along with a bunch of concrete instances which are dependent upon the FooBase class protected interface and code implementation. This creates the brittle base class problem.<p>If instead you had an IFoo interface and only ever used List<IFoo> instead of FooBase anywhere then you could always define FooBasev2 which implemented IFoo as well and FooBase and FooBasev2 can coexist in your codebase without having to break any external consumers (open-closed principle in practice).<p>If base classes were only allowed to be used in inheritance and couldn't be parameters, generics, etc then that would force users to create base classes and public interfaces in pairs and would decouple their names and by writing the public interface down as its own thing developers would be more likely to focus on that design.<p>And really inheritance is just syntax sugar around having a component (the base class) which has automatic delegation of of the public interface and protected interface to it in the inheriting object, with so little typing that it becomes easy to not think about what you're doing -- and while reusing the same name for three different things and creating tight coupling, and you can't dependency inject different baseclasses at runtime. If languages had better terse syntax for delegation then composition would get a lot easier to use like inheritance is (which is something that Go oddly enough gets more-or-less correct, dunno why they didn't mandate piles of boilerplate for delegation like they did for error checking).
I think it is pretty clear that the reason inheritance is so prevalent is because it is a superficially good sounding idea, which again and again is being put in front of people.<p>I am sure that many, many people have had the experience of a professor tell them a nice sounding story about purely hierarchical data and went on thinking that this is the way data should be modeled.<p>Thankfully I believe that nowadays many people have understood what works and what doesn't work in OOP and we can actually try to get away from that model of data.
As a programmer with likely less experience than most of these commenters, the main question that always feels under addressed in these kinds of posts is that of code deduplication.<p>Most specifically, often when encountering a situation in which I have two slightly different classes/types that need to be polymorphic with each other, all the standard non-inheritance based approaches seem to require a lot of outright identical code implementing a shared interface, a bunch of boilerplate composition proxy methods that just point to methods in a composed class, or weird and obscure language features that never really feel like the "intended" approach.<p>Typescript especially seems to demand really awkward and obtuse implementations of basic mixins or abstract classes and the like, I always feel like I'm missing the more "intended" approach whenever I try to share code between similar classes.<p>Often discussions around this are awash with talk of traits and delegates and other cool features that seem to only exist in a handful of languages, and never the ones I happen to be required to use at that given moment.
Kotlin has a few nice patterns here. It allows inheritance but only if you mark your class as open (it's closed by default). This prevents people inheriting from things that weren't designed from that. It also has extension functions, which allows you to add functions and properties to types without having to inherit from them. This is very nice for fixing things that come with Java libraries to be a bit more Kotlin friendly. Spring offers a lot of Kotlin extension functions for its Java internals out of the box. Another nice pattern is interface delegation where you can implement an interface and delegate to another object that implements that interface:<p><pre><code> class Foo(private val myMap: Map<String,String>=mapOf()): Map<String,String> by myMap
</code></pre>
This creates a Foo class that is a Map that delegates to the myMap property under the hood. So you side step a lot of the issues with inheritance; like exposing the internal state of myMap. But you can still override and extend the behavior. Replacing inheritance with delegation is built into the language.<p>The net result of this is that inheritance is rarely needed/used in Kotlin. It's there if you really need it but usually there are better ways.<p>Scala and other languages of course have similar/more powerful constructs. But Kotlin is a nice upgrade over Java's everything is non final by default (or generally defaulting to the wrong thing in almost any situation). Go has a nice pattern based on duck typing where instead of declaring interfaces, you can just treat something that implements all the right functions as if it implements a type. Rust similarly has some nice mechanisms here. All these are post-Java languages that de-emphasize inheritance.
IMHO inheritance works and only works for graphics related programming, e.g. GUI and games. Visual objects can be abstracted in the manner of inheritance.
My take is that after something becomes sufficiently popular and mainstream, for a lot of people who want to be seen as innovative, the only way is to lash out against it. See all the articles on how hellishly bad agile, php or javascript is. A lot of criticism is valid of course, but that is irrelevant in the larger scheme of things - there is a reason they became what they are today.
My impression is the opposite, especially from when I used to work as a full-time Java dev. I often asked myself:<p>Is there a place outside of GUI programming where inheritance is used in non-habitual and useful way? I can't think of many.<p>More often than not you have a final class that you are supposed to use and the petrified hierarchy above that is of not much use.
I don't think that inheritance is bad per se. AbstractWindowButtonManagerFactory type of inheritance is bad. I think the reason is that people are not just good at constructing hierarchical relationships between abstract concepts. And once you construct such an elaborate hierarchy, it becomes very hard to correct things after the fact. So you end up with a mess as people add more functionality on top of an already ill-conceived structure.
I only use inheritance for what the author calls ontological inheritance. For example, I find it useful to represent expressions and statements. I prefer composition if I'm trying to reuse data structures.
OOP is easy to understand and explain and it makes sense initially, plus a lot of people specialize in languages/frameworks that enforce it, so it becomes easy to get trapped in the OOP world. It also usually comes with DDD (which is a solution to a problem you shouldn't have had in the first place) which is a way to limit the damages of OOP into contextual areas.
I also think the blanket statement (OOP is bad) does not apply necessarily everywhere. A good mix of composability and a bit of inheritance where it makes sense is the best way imo.
Not even wrong.<p>Inheritance isn't necessarily bad.<p>If anything is common, someone will try to seem like a brilliant iconoclast by writing an essay against it. The particular essay in this case was from a Pythonista (not surprising, given Python's weird love/hate with objects):<p><a href="https://solovyov.net/blog/2020/inheritance/" rel="nofollow">https://solovyov.net/blog/2020/inheritance/</a><p>And not everyone uses inheritance.<p>Maybe you have another question, like "why would someone use inheritance?"
IDK, I recently did a big presentation on the topic in my company's Python community and there were tons of people that were genuinely surprised it's not great. And people in my department love throwing random classes that inherit from everything in the universe for no reason at all... for python. Like not even Java or C#. And coming in as the lone new-comer its not going to be easy to convince everyone that has been there for years that the common sense aint great.
Some modern programming languages do not even have classes to inherit from. Instead they have concepts like traits and structs, which decouple structure and behavior.
My situation is different than a lot of others--I work mostly with code-bases I 100% control--but I just don't use inheritance all that often, and if I do, it's never deeper than one or two levels. Now, I do most of my programming in Python and in JavaScript, and I do like using python's ABCs to specify interfaces for interfaces that I expect to be implemented, but that's mostly the end of it.
It can be useful in the situation where you want to override functionality in a class without making the functions public.<p>If you're composing a class out of multiple chunks of functionality then all of the bits you want to call need to be public. If you're sublcassing and overriding then the bits you're overriding can be internal, and not part of your public API.
Depends what language you're using and what polymorphism features it has...<p>C - You don't use inheritance because it literal has none, but you can handroll dynamic dispatch (interface style Abstract Base Classes)<p>Rust - Also doesn't have it and people seem perfectly happy with generics, sum-types, and `dyn Trait`
I look mostly at JS and some Rust codebases and almost nobody uses inheritance!<p>I believe it doesn't make any sense, you can use different patterns to have the benefits without creating a complicated type hierarchy where state and functions are mixed across different files.<p>Whenever I would use inheritance I use the builder pattern.
Inheritance is not so bad for native UI stuff where it makes sense for the class libraries.<p>But in work code I don’t see it much. If it is used it is light weight. Often used incorrectly for splitting code into different files rather than actual inheritance (giveaway is one one derived class!)
I find that it helps most if we make algorithms the centerpiece of the design and then use inheritance to facilitate coding and make everything succinct.
The days of unwieldy inheritance structures coming out of big design patterns are clearly over.
Nerds make things complicated, no matter what. It is their fundamental impulse that cannot be tamed, like the scorpion who must sting the frog that carries it across the river.
Many of the headaches associated with Rust come from an inability to reference from owned to owner. Affine types have much more impact on design than inheritance vs. composition.
I think there’s a tension between the tinkerer, blogger and hobbyist side of the field, and anonymous 9–to-5 workhorse line of business programming in this discussion.<p>The core reason everyone uses it seems to me to be essentially the same reason the former groups hate it - it’s what everyone else does, it’s an incredibly square and “day-job”-esque approach to one’s tooling and architecture, it often reeks of bureaucracy, compartmentalization, and organizational superstructures often unrelated to the technical work, dictated primarily by managerial fiefdoms and needs to organizationally coordinate, and it’s a well-defined space with extremely predictable solutions and headaches, and therefore has very little excitement or novelty to offer.
We don't use inheritance anymore. In all the years building small and hughe software solutions with small and larger teams I've never experience any real scaling, maintenance or resilience benefit. Even for documentation it is more a pain for new devs onboarded than an advance. Patterns,DRY, DI, IOC, MS, ES, IO are best to build with these scopes in head.
One thing that bothers me is when people refer to languages like Go and Rust as "not object-oriented". Of course they are object oriented; Go and Rust programs consist of struct definitions to which you associate methods, giving rise to individually instantiatable objects with custom behavior, and you use these objects to model entities in your problem domain. This is object-orientation.<p>Where they differ from OO languages such as Java and Python is of course that they avoid traditional inheritance, offering more restricted inheritance-adjacent features (typeclasses/traits/interfaces and struct embedding).<p>Like many others I find Go disappointing in many regards. (Although Go's channels, goroutines, select, and implicit interfaces are beautiful). One disappointment is the way that methods are not indented or nested within the struct definition/interface that they are defined on. This is, IMO, a silly fig-leaf that is attempting to make the language look "not OO" in a superficial manner, but all it ends up doing is making it hard to see where your implementation of one interface ends and another starts.
Oh, darling, strap in because the Hacker News catwalk is serving us a spicy mix of opinions on inheritance in programming!<p>First up, we've got the crowd who treats CSS like it’s the ugly stepchild of inheritance, preaching the gospel of "composition over inheritance" as if it's the latest fashion trend.<p>Then there's the old guard, clutching their pearls and insisting that inheritance isn't the problem—it's just misunderstood, like a moody teenager.<p>Cue the functional programming aficionados, sashaying in with their "functions over classes" mantra, ready to throw shade at OOP's entire existence.<p>And let’s not forget the star of the show, the claim that inheritance is the VIP at the GUI and game development party, although some party poopers argue that the cool kids moved on to ECS systems ages ago.<p>Meanwhile, the language innovators are flaunting their Kotlin and Swift ensembles, dripping in modern features that promise to make inheritance feel so last season.<p>In the midst of this fashion war, there's a heated debate on whether we should be dressing our newbie programmers in OOP gowns or functional frocks from day one. And, honey, let’s not even get started on the industry’s trend chasers, who once hailed OOP as the next big thing, only to ghost it faster than you can say "blockchain."<p>In the end, it’s clear that in the world of programming, inheritance is either a timeless classic or a faux pas waiting to happen, depending on who you ask.
I work on a very large codebase. We use inheritance and composition. I totally agree that inheritance should be used carefully. However, there are times when composition requires a lot more code and downstream maintenance.<p>Let's stay I have a base class A.
Let's say I have 70 classes that inherit from A.<p>These classes must serialize/deserialize from disk.<p>My choice here is that I can add a new data member to A and then update the read/write method in one place, or I add a new data member to all the classes that are derived from A, meaning that I get to update 70 classes. Seriously? Who would think this is a good idea? You'll have to write 70 times as much code... there will be times when that's definitely a very bad idea.<p>Maybe don't use inheritance. Then give every class its own "Name" data member like std::string c_nName. Every class can have its own function to set the name, or we could use an unencapsulated free function and do things like C. Except then the experts will say things like "well, now you're doing C with classes". Then you get a ticket that the user can enter bad names. You can then figure out some way to validate the names, right? That could be a free function, or maybe write some class called NameValidator. Except now the experts say you're writing C++ like Java. Too many classes, too few classes, too many objects, too few objects, too may free functions, too few free functions.<p>C++ expert of the month may say X, Y, Z, but look at Microsoft's APIs.<p>Inheritance is everywhere.<p>Look at any open source C++ project.<p>Inheritance is everywhere.<p>Does that mean that you should make something like:<p>A<p>--B : public A<p>----C : public B<p>------D : public C<p>--------E : public D<p>----------F : public E<p>Or this:<p><pre><code> A B
\ /
C
</code></pre>
Not unless you have a damn good reason. But the point is that inheritance is a valid tool and it can reduce bugs, code duplication, maintenance.<p>Right tool for the job, yeah? I once read something in the C++ FAQ that said something like "Don't take advice from people who don't understand your business problems."
When I learned programming as a teenager, I was using one of the C++ classics which, of course, taught OOP and Inheritance as a magic silver bullet.<p>When I then finished the book and its examples, I wanted to do my own exercises and went through about 1-2 very painful years trying to model my things using Inheritance and totally blamed myself for being too stupid to do software development.<p>Only then I started searching and finding essays and blog posts of people criticizing OOP and esp. Inheritance for exactly the things I was struggling with. This felt like a relief!<p>My question: Why is Inheritance still taught as a silver bullet? I'm seeing university courses using Inheritance both for Domain and infrastructural code reuse at the same time. Esp. in Germany I see a lot of stupid 90s alike "programming" courses and, no shit, according code bases. It's as if they were living in a gigantic bubble.
It's not bad. People like to feel smug by saying OO is bad and hence inheritance, meanwhile using some construct in their FP that is really the same thing.
Black and white extremist views.<p>Sometimes inheritance is extremely useful.
Sometimes it's harmful.
Sometimes it's not the best but the most practical nontheless.<p>Language concepts are tools. These people with extreme black and white views live under the delusion that there can be some "Perfect Language which will cause the program to never develove/get technical debt TM".<p>Pure delusion.<p>Real life is an approximation where you do what is best in practice, not in some delusional daydream of perfection which breaks the moment you try and bring it to reality.
For a really neat implementation of OOP and inheritance, I would recommend checking out Racket's class system (not to be confused with generics). It mostly solves the multiple inheritance problem by mixins and also has a great interface system.
I love the way people take their narrow range of experience and over generalize it to everything. Bonus points for having a blog or maybe a patreon to tell everyone how it really is.<p>We have a million flavors of the month but in the end it doesn't really matter. Pick a flavor and there will be teams that are successful and teams that are not. No silver bullet will make the non-successful teams magically turn into successful ones.<p>"I/We failed with <insert language feature>" never generalizes to "<insert language feature>" is bad.<p>Then the community constantly sits there and acts like a bunch of geniuses because some programming pattern has been discovered.. except it's 50 years old.
Boring answer: Same reason we do a lot of stupid things, haha.<p>“If C is so unsafe and C++ is so unwieldy why does anyone use them?”<p>Because that’s what they learned, or because that's how the codebase is structured when you get there. When all you have is a bike you’re going to ride that shit everywhere.<p>You rarely if ever get the chance to start from scratch at work (where most code is written) and your job is to follow the pre-set pattern most of the time unless it becomes completely untenable. Sure, inheritance is worse in pretty much every way, but if everyone you're hiring does it that way, your codebase is built that way, etc, you're going to make the best of it because that's your job.