Having chewed on this for a while now, my personal synthesis is this: The problem with OO is actually a problem with "inheritance" as the default tool you reach for. Get rid of that and you have what is effectively a different paradigm, with its own cost/benefit tradeoffs.
Inheritance's problem is not that it is "intrinsically" bad, but that it is too big. It is the primary tool for "code reuse" in an inheritance-based language, and it is also the primary tool for "enforcing interfaces" in an inheritance-based language.
However, these two things have no business being bound together like that. Not only do I quite often just want one but not the other, a criticism far more potent than the size of the text in this post making it indicates (this is a huge problem), the binding introduces its own brand new problem, the Liskov Substitution Principle, which in a nutshell is that any subclass must be able to be be fully substituted into any place where the superclass appears and not only "function correctly" but continue to maintain all properties of the superclass. This turns out to be vastly more limiting than most OO programmers realize, and they break it quite casually. And this is unfortunately one of those pernicious errors that doesn't immediately crash the program and blow up, but corrodes not only the code base, but the architecture as you scale up. The architecture tends to develop such that it creates situations where LSP violations are forced. A simple example would be that you need to provide some instance of a deeply-inherited class in order to do some operation, but you need that functionality in a context that can not provide all the promises necessary to have an LSP-compliant class. As a simple example of that, imagine the class requires having some logging functionality but you can't provide it for some reason, but you have to jam it in anyhow.
It is far better to uncouple these two things. Use interfaces/traits/whatever your language calls them that anything can conform to, and use functions for code reuse. Become comfortable with the idea that you may have to provide a "default method" implementation that other implementers may have to explicitly pick up once per data type rather than get "automatically" through a subclass inheritance. In my experience this turns out to happen a lot less than you'd think anyhow, but still, in general, I really suggest being comfortable with the idea that you can provide a lot of functionality through functions and composed objects and don't strain to save users of that code one line of invocation or whatever.
Plus, getting rid of inheritance gets rid of the LSP, which turns out to be a really good thing since almost nobody is thinking about it or honoring it anyhow. I don't mean that as a criticism against programmers, either; it's honestly a rather twitchy principle in real life and in my opinion ignoring it is generally the right answer anyhow, for most people most of the time. But that becomes problematic when you're working in a language that technically, secretly, without most people realizing it, actually requires it for scaling up.
> Plus, getting rid of inheritance gets rid of the LSP
No it doesn't. Interfaces need to follow substitutability rules too. Any type you substitute for another does, and that includes things like functions too.
It does, because it is no longer a matter of substitutability. You are not intrinsically taking an X and modifying it to become a Y while also being an X. You are now just providing an X, and another X, and another X, and another X over there. You need to maintain the constraints of the one interface you are satisfying, but you are not also maintaining the constraints of the superclass, and all of its superclasses. You only have the interface to worry about, only the one dimension, not two (or more, depending on how you count in multiple inheritance languages).
You also can do things like take a subset of the interface and have things that implement just that. You can't do that to a class hierarchy; once a method is put in the hierarchy, it must be implemented by all children. (Note that if you're jumping up to say "But I can just implement an interface in Java or whatever if I want to do that", you're agreeing with me, not disagreeing. That's not a legal move in inheritance, though. Languages have been very, very slowly but very surely moving away from pure inheritance for a long time now.)
Having interfaces separated from reusability means you don't have to worry about all these things at once, just the interface.
I think trying to overformalize this by bringing in LSP might make it harder to understand and easier to nitpick. Another way to look at the same thing is that subclassing/implementation inheritance is an extremely stringent but poorly enforced contract (yeah, also a kind of formalism) that's, in your typical OO language, far too easy break without noticing.
Ironically, the fact that LSP is complicated and to a first approximation nobody understands it is a major part of my point.
(Or, if you prefer, LSP itself isn't that complicated conceptually, but if you try to manifest it in reality it turns out to be very complicated in practice. Code makes a lot more guarantees than we think it does. See also https://hyrumslaw.com/ , which a very different view on the same phenomenon.)
I agree. I think the LSP makes it essentially impossible to subclass a concrete superclass, because the subclass must retain all the observable behaviour of the superclass. If it does so then what's the point? On the other hand, implementing an interface is fine. Different implementations of the interface can just uphold the interface invariants without needing any relationship to each other.
It is much harder to violate LSP by writing new code which simply adheres to an interface, than it is to violate by writing new code which is run instead of the old code (and all the old code's side effects)
Inheritance's problem is not that it is "intrinsically" bad, but that it is too big. It is the primary tool for "code reuse" in an inheritance-based language, and it is also the primary tool for "enforcing interfaces" in an inheritance-based language.
However, these two things have no business being bound together like that. Not only do I quite often just want one but not the other, a criticism far more potent than the size of the text in this post making it indicates (this is a huge problem), the binding introduces its own brand new problem, the Liskov Substitution Principle, which in a nutshell is that any subclass must be able to be be fully substituted into any place where the superclass appears and not only "function correctly" but continue to maintain all properties of the superclass. This turns out to be vastly more limiting than most OO programmers realize, and they break it quite casually. And this is unfortunately one of those pernicious errors that doesn't immediately crash the program and blow up, but corrodes not only the code base, but the architecture as you scale up. The architecture tends to develop such that it creates situations where LSP violations are forced. A simple example would be that you need to provide some instance of a deeply-inherited class in order to do some operation, but you need that functionality in a context that can not provide all the promises necessary to have an LSP-compliant class. As a simple example of that, imagine the class requires having some logging functionality but you can't provide it for some reason, but you have to jam it in anyhow.
It is far better to uncouple these two things. Use interfaces/traits/whatever your language calls them that anything can conform to, and use functions for code reuse. Become comfortable with the idea that you may have to provide a "default method" implementation that other implementers may have to explicitly pick up once per data type rather than get "automatically" through a subclass inheritance. In my experience this turns out to happen a lot less than you'd think anyhow, but still, in general, I really suggest being comfortable with the idea that you can provide a lot of functionality through functions and composed objects and don't strain to save users of that code one line of invocation or whatever.
Plus, getting rid of inheritance gets rid of the LSP, which turns out to be a really good thing since almost nobody is thinking about it or honoring it anyhow. I don't mean that as a criticism against programmers, either; it's honestly a rather twitchy principle in real life and in my opinion ignoring it is generally the right answer anyhow, for most people most of the time. But that becomes problematic when you're working in a language that technically, secretly, without most people realizing it, actually requires it for scaling up.