I think everyone can agree that OO as most aggressively sold in the 90’s was a flawed fiction. In that pitch, the idea was that one could simply make classes and this would become reusable code and one could just use one’s intuition of real world objects and ontologies and these would become effective program designs. Of course this is wrong.
You can improve the OO paradigm by making it more circumspect or jump an entirely different approach.
But I’d also mention that “the problems themselves remain”. Which is to say that I see the fundamental problem is what happens when one tries to leverage everyday ontologies and object-intuitions to the world of computer science.
The “diamond problem” and related questions wind-up ultimately problems of reducing a fuzzy world to a clear hierarchy. And this problem exists regardless of the programming and design paradigm you use.
So I suppose my main point is that design is going to be hard no matter what the paradigm - which isn’t really a statement about which paradigm is better but rather just a statement that design is hard and changing paradigms isn’t going to eliminate that hardness.
Not necessarily. You can have objects without inheritance, as Go does, which avoids the diamond problem.
@joe_the_user might be referring to the fact that, inheritance or not, humans organize information hierarchically and defining that hierarchy wrong leads to awkward situations. In OO with inheritance it becomes an unfortunate code artifact. Without inheritance it becomes an awkward documentation/understanding artifact. But either way, the problem of coming up with the correct hierarchy exists.
Or allow single inheritance only, but no multiple inheritance (And no getting around it by using interfaces, hi Java!) so you can only get a “line” configuration, never a “diamond”.
Or you just use multiple inheritance, but without the diamond problem.
The diamond problem is an issue with the specific design approach C++ picked. It’s no inherent to multiple inheritance.