I can count on 0 hands how many times I have used inheritance in the past 6-7 years. And if you don't count times that a framework requires me to use it to accomplish something, like React.Component or NSTableView, then that number goes back something like 15 years.

It boggles my mind that inheritance is still taught in schools and universities. It's so easy to debunk the common lovely idea of "Square and Circle are a type of Shape, Rectangle is a type of Square" that it's not even worth talking about it -- you might want the square to be rendered in a GUI framework but have the Circle rendered only in your PDF reports, being one very lame example I can think of in under a minute. Many others exist on the net and they are much better than mine.

(Traits of types -- and thus multiple inheritance -- make much more sense if you so want to model the real world.)

"OOP is necessary" is a lie that is worth billions of dollars. Inheritance ends up being leaky and non-isolated. Every time.

Inheritance works great in mathematics because then it's all about using some laws to compute derived properties, but in programming we use objects for behavior with side effects. So it's like apples and oranges.

I’m not really sure where you think mathematics is full of inheritance. Do you have an example?

Off the top of my head:

Subsets, sub-anything-else, not really inheritance

Definitions of the form an X is a Y with the following extra properties, I think don’t really count as inheritance either. Example: A ring is a group with ..., but if you wanna to prove anything interesting about a ring, you can’t kust use the group properties or you would have proven a theorem about a group, and so the only useful thing about the group structure is that you know what it is. Any useful theorems will need other useful definitions (eg homomorphism) and these don’t get inherited and so the isomorphism theorem for groups doesn’t become the isomorphism theorem for rings “for free”. There’s also the fact that a field is a ring plus an extra property but most ring things become basically useless because much ring weirdness becomes trivial in a field and what is not trivial in a field is typically impossible in a ring, so knowing about rings doesn’t tell you much about fields.

Example: a topological space is a set plus a subset of its power set such that ... but all the interesting things in topology typically have little to do with those sets and more to do with eg functions (but not just any set function) and the added properties.

I suppose the theme is that one adds structure to (ie inherits from?) something because the new structure bans a lot of the weirdness of the bigger thing and allows for more interesting things to be done. The structure of the bigger thing is therefore not so useful because what is known about it is less relevant once more structure is imposed.

In applied maths, the Fourier and Laplace transforms are part of a more general family of integral transforms yet this knowledge is basically useless in their application and it would not make much difference if they were not related.

Fourier series fall into part of a bigger theory called Sturm-Liouville theory but in many of the places one uses a Fourier series this bigger picture is not relevant whereas the specific details about Fourier series are. This is not to say that Sturm-Liouville theory is not useful.

If you're merely a consumer of libraries and frameworks then you won't use inheritance very much but if you're a designer of libraries and framework will use it almost all the time.

I love that inheritance lets me customize 3rd party code and integrate with it smoothly; nothing pisses me off more than a "sealed" class that you can't inherit from.

> integrate with it smoothly

"Smoothly". For my 8 years with Java the only base classes that haven't been retroactively modified and thus breaking my inherited classes... were the ones in the stdlib. Everything else could and has been pulled under my feet, many times.

Everyone and their moms and dogs was like "hey, I think I can do better because I feel great this week!" and then 10 of us had to repair an object hierarchy of 200+ classes. I mean, everybody knows the CTO can't make a mistake, right?

And don't give me the "not in a disciplined team!" argument. Even disciplined teams make mistakes because often the author has no idea how many other colleagues use their base class.

I know the idea sounds too good to ever believe that it can't be true -- but yeah, it's not true.

> nothing pisses me off more than a "sealed" class that you can't inherit from

The "sealed" classes are meant to be semantic boundaries. Get an instance of it in your object and be done with it. What's so triggering about that?

But you don't have an alternative. You subclassed things and someone broke the base class. It happens. But there is no other magic bullet (whether it be all functional programming or something else) that solves that problem. Most just make extension impossible, which isn't really better.

> The "sealed" classes are meant to be semantic boundaries.

The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right?

> The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right?

...What?

You can compose an instance of the sealed class in yours. You lose all brittleness from inheritance in the process. I've been coding OOP most of my life and I am working with FP for 2 years now -- composition never introduced a bug. Sure it's anecdotal but after a trend repeats itself 5+ times, you start observing patterns and making conclusions.

Additionally, a number of FP languages offer Java-like and Go-like interfaces for an extra peace of mind.

> You can compose an instance of the sealed class in yours.

But I can't subclass a sealed class to fix a bug or add a feature and pass it back into the framework to use. And yes, I have needed to do this otherwise I would never notice it was sealed in the first place.

That's exactly what I hate about Cocoa. Sure Carbon wasn't perfect, but subclassing NSTableView so that you can inject your subclassed NSTableHeaderView just to make some UI tweaks is awful. The entire framework is like this, and Swift doesn't help much. I get that it's a legacy design due to performance issues back from when Cocoa was created 25 years ago, but I would absolutely love to see a modernized macOS UI framework where functions were always used in place of delegates or subclassing, and where lexical scoping is the backbone of your app's own internal architecture instead of class hierarchies.

> functions were always used in place of delegates or subclassing

I'm not sure what this means? In your modernized UI framework, how would you want to be able to make UI tweaks to built in OS/framework components?

I've seen a few other system for customization and they all tended to be worse than just being able to subclass internal classes and override methods. Now I admit this can be terribly brittle but often the alternative is no way to customize at all.

I guess instead of overriding methods like “windowDidLoad”, you would set a function (I mean block) as “window.loadHandler” or something like that.

I don’t really see why this would be better, to me the two approaches seem isomorphic...

Use higher order functions to customise behaviour. I.e. your hypothetical NSTableView would look like this:

    nsTableView ::
      { renderCell :: a -> NSView   -- this is the function that renders a cell given an `a`
      , header     :: NSView
      , footer     :: NSView
      }
      -> [a]
      -> NSTableView a

I.e. pass in a function that renders a cell for a given `a`, a header and a footer NSView and whatever else, a list of `a`s and get back a NSTableView which displays that list of `a`s.

React calls this pattern higher order components iirc.

As the other commenter pointed out, this seems pretty isomorphic to virtual methods.

Two obvious differences off the top of my head:

1. Overriden methods have access to the internal state of the parent class, which is almost universally a bad idea.

2. Since functions are values, you can freely mix and match different view configurations without having to create a subclass for every permutation.

#1 isn't true; you only have access to the state that subclasses are allowed to have (assuming you're using a language with any protection at all).

#2 is a good point. But there are some limitations as well. You don't get to augment the default implementation unless it is also exposed somewhere (passed into the function).

Both methods have a lot in common with the obvious differences that you mention. A class with no public methods and a empty virtual function is equivalent to a class calling a higher order function in the same place. If that virtual function has a implementation, you can get the same functionality with a higher order function by passing in the base implementation as a parameter. For full equivalence, you could also pass the object instance as well. Add in protected methods and/or state and you can get that with a second class that implements an internal API and again pass that to the higher-order function.

Ultimately you can achieve all kinds of equivalence this way. I think there is some advantage to using the terminology in the language (private, protected, virtual, abstract, this/base, etc) to describe the more complex situations. Having a simple function call is useful for more simple situations. This is the classic struggle.

Can you elaborate on what you do when inheritance feels quite natural? A classic example would be to allow a plugin. For that natural thing to do would be to define base abstract class with bunch of overridables, utility methods and pure virtual interface methods. I can imagine it doing without OOP but it doesn’t seem as clean or natural.

I wouldn't say Go has anything comparable to Rust traits.

https://softwareengineering.stackexchange.com/questions/2472...

Neither Go nor Rust are mainstream -- that's still C++, Java and Javascript.

Go is #12 on the TIOBE index, and by that measure more mainstream than Perl or Ruby. If by mainstream you mean "the top 3-5 programming languages", then you're not talking about anything invented in the last 20 years, which is kinda the point.

New languages can reflect mainstream opinions even if the languages are not mainstream. Mainstream languages tend to represent fossilized opinions from the time when they were designed.

If we were to use a car analogy: go has been in production for the last few years and there's a ton on the road, but the average car on the road wasn't built in the last few years.

The mainstream is not only defined by what's most popular, but also by what sets the trends. The masses always get the message with some delay...

Besides, all of the three languages that you've mentioned are turning more functional and less OO with each year...

JS still has OO (and recently got "classes" as sugar), but it's not used in the crazy deep-OO-hierarchy style at all.

Java, that used to cherish that style also abandons it nowadays (with closures, streams, etc.).