Inheritance was invented as a performance hack (2021)

I&#x27;m not sold the evidence is there to show inheritance is a good idea - it basically says that constructors, data storage and interfaces need to be intertwined. That isn&#x27;t a very powerful abstraction, because they don&#x27;t need to be and there isn&#x27;t an obvious advantage from doing so over picking up the concepts separately as required. And inheritance naturally suggests grouping interfaces into a tree in the way that seems of little value because <i>in practice</i> a tree probably doesn&#x27;t represent the fundamental truth of things. Weird edge cases like HTTP over non-TCP protocols or rendering without screens start throwing spanners into a tree of assumptions that never needed to be made and pull the truth-in-code away from the truth-in-world.<p>All that makes a lot of sense if it was introduced as a performance hack rather than a thoughtfully designed concept.

Discussed at the time:<p><i>Inheritance was invented as a performance hack</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26988839">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26988839</a> - April 2021 (252 comments)<p>plus this bit:<p><i>Inheritance was invented as a performance hack</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35261638">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=35261638</a> - March 2023 (1 comment)

I think a lot of the arguments against inheritance come from C++&#x27;s peculiar implementation of it, which it clearly, ah, inherited from Simula. Slicing, ambiguous diamond inheritance, stuff like that are C++ problems, not inheritance problems. This isn&#x27;t to say inheritance isn&#x27;t problematic, but when you&#x27;re making a properly substitutable sub-<i>type</i> of something, it&#x27;s hard to beat.

There is this wonderful presentation by Herb Sutter talking about how the C++ concept “class” covers over 20 other abstractions, and that Bjarne’s choice for C++ was the right choice since it offers so much power and flexibility and expressive power in a concise abstraction.<p>Other languages (just like the article) only saw the downsides to such a generic abstraction that they added N times more abstractions (so split inheritance, interfaces, traits, etc) and rules for interactions that it significantly complicated the language with fundamentally no effective gains.<p>In summary, Herb will always do a better job than me explaining why the choices in the design of C++ classes, even with multiple inheritance, is one of the key factors of C++ success. With cppfront, he extends this idea with metaclasses to clearly describe intent. I think he is on the right track.

I find that structural typing is the most useful thing and unfortunately few languages support it. I&#x27;d like a language where:<p>- If I have a class Foo and interface Bar, I should be easily able to pass a Foo where Bar is required, provided that Foo has all the methods that Bar has (sometimes I don&#x27;t control Foo and can&#x27;t add the &quot;implements Bar&quot; in it).<p>- I can declare &quot;class Foo implements Bar&quot;, but that only means &quot;give me a compilation error if Bar has a method that Foo doesn&#x27;t implement&quot; - it is NOT required in order to be able to pass a Foo object to a method that takes a Bar parameter<p>- Conversely, I should be able to also declare &quot;interface Foo implementedBy Baz&quot; and get a compilation error if either one of them is modified in a way that makes them incompatible (again - this does not mean that Baz is the _only_ implementor, just that it&#x27;s one of them)<p>- Especially with immutable values - the same should apply to data. record A extends B, C only means &quot;please verify that A has all the members that B &amp; C have, and as such whenever a B record is required, I can pass an A instead&quot;. I should be able to do the reverse too (record B extendedBy A). Notably, this doesn&#x27;t mean &quot;silently import members from B, and create a multiple-inheritance-mess like C++ does&quot;.<p>(I do understand that there&#x27;d be some performance implications, but especially with a JIT a feel these could be solved; and we live in a world where I think a lot of code cares more about expressiveness&#x2F; understandability than raw performance)

We use the word inheritance to refer to two concepts. There is implementation-inheritance. There is type-inheritance. These ideas are easily confused, which should be cause to have distinct words for them. Yet we don&#x27;t. (Although Java does, effectively)

Huh, I was always told that inheritance hurt performance as it requires additional address lookups. Thats why many game engines are moving away from it.<p>I guess it could simplify the GC but modern garbage collectors have come a long way.

IMHO Inheritance (especially the C++ flavored inheritance with its access specifiers and myriad rules) has always scared me. It makes a codebase confusing and hard to reason with. I feel the eschewing of inheritance by languages such as Go and Rust is a step in the right direction.<p>As an aside, I have noticed that the robotics frameworks (ROS and ROS2) heavily rely on inheritance and some co-dependent C++ features like virtual destructors (to call the derived class&#x27;s destructor through a base class pointer). I was once invited to an interview for a robotics company due to my &quot;C++ experience&quot;and grilled on this pattern of C++ that I was completely unfamiliar with. I seriously considered removing C++ from my resume that day.

I always thought this was common knowledge. I guess it isn’t.<p>The only reason inheritance continues to be around is social convention. It’s how programmers are taught to program in school and there is an entire generation of people who cannot imagine programming without it.<p>Aside from common social practice inheritance is now largely a net negative that has long outlived its usefulness. Yes, I understand people will always argue that without their favorite abstraction everything will be a mess, but we shouldn’t let the most ignorant among us baselessly dictate our success criteria only to satisfy their own inability to exercise a tiny level of organizational capacity.

I think many developers, especially in the range on 1999-2020, has gone through many pitfalls in programming. More specifically.. OOP.<p>As someone who was blessed&#x2F;lucky to learn C and Pascal.. with some VB6.. I understood how to write clean code with simple structs and functions. By the time I was old enough to get a job, I realised most (if not all) job adverts required OOP, Design Patterns, etc. I remember getting my first Java book. About 1,000 pages, half of which was about OOP (not Java directly)<p>I remember my first job. Keeping my mouth shut and respecting the older, more experienced developers. I would write code the way I believed was correct -- proper OOP. Doing what the books tell me. Doing what is &quot;cool&quot; and &quot;popular&quot; is modern programming. Hiding the data you should not see, and wrapping what you should in Methods... all that.<p>Nobody came to me and offered guidance but I learned that some of my older codebase with Inheritence, Overrides.. while it was &quot;proper&quot; code, would end up a jumbled mess when it required new features. One class that was correctly setup one day needed to be moved about, affecting the class hierarchy of others. It brings me back to thinking of my earlier programming days with C -- and to have things in simples structs and functions is better.<p>I do not hate on OOP. Afterall, in my workplace, am using C# or Python - and make use of classes and, at times, some inheritence here and there. The difference is not to go all religious in OOP land. I use things sparingly.<p>At work, I use what the Companies has already laid out. Typically languages that are OOP, with a GC, etc. I have no problem with that. At home or personal projects, I lead more towards C or Odin these days. I use Scheme from time-to-time. I would jump at the opportunity to using Odin in the workplace but I am surrounded by developers who dont share my mindset, and stick to what they are familiar with.<p>Overall, his Conclusion matches my own. &quot;Personally, for code reuse and extensibility, I prefer composition and modules.&quot;

Favorite part of this is that I had no idea if this article was going to be about biology, code or money. I love a good surprise

I know we&#x27;re on Hacker News, but I would have preferred a more explicit title (programming language, not wealth across generations).

Before my time but I reject the idea that inheritance was &quot;invented&quot; in the context of a particular high level programming language. It was used widely in assembly&#x2F;machine code programming. It&#x27;s essentially a manifestation of two things: categorization of things (at least thousands of years old); and pointers to data structures (at least as old as the Manchester Mk1).

Fascinating.<p>Interestingly enough, my first non-class-related experience with &quot;intrusive lists&quot; was in C, and we implemented it via macros; you&#x27;d add a LINKED_LIST macro in the body of a struct definition, and it would unspool into the pointer declarations. Then the list-manipulation functions were also macros so they would unspool at compile time into C code that was type-aware enough to know where the pointers lived in that individual struct.<p>Of course, this meant incurring the cost of a new definition of function families for each intrusive-list structure, but this was in the context of bashing together a demo kernel for a class, so we assumed modern PCs that have more memory than sense. The bigger problem was that C macros are little bastards to debug and maintain (especially a macro&#x27;d function... <i>so</i> much escaping).<p>C++, of course, ameliorates almost all those problems. And replaces them with other problems. ;)

All of what we take for granted in modern computing architecture was invented as a performance hack by von Neumann in 1945 to take advantage of then-novel vacuum tube tech.

What do folks think of the OCaml&#x2F;SML style approach with its signatures+modules+functors? It&#x27;s a bit obscure, and some people find it inconvenient. Inheritance in their approach can be approximated using functors.

Performance is not a hack. Title is wrong... ;-)<p>Interfaces are indeed much nicer, but you have to make sure that your program language doesn&#x27;t introduce additional overhead.<p>Don&#x27;t be the guy that makes Abstract Factory Factories the default way to call methods. Be aware that there are a lot of people out there that would love to ask a web-server for instructions each time they want to call a method. Always remember that the IT-Crowd isn&#x27;t sane.

This title is so wild when you read it without the context of software development...