Hierarchy - a single ontology - is one of the problems with OO. Ontologies - note the plural - are useful, but choosing just one ontology privileges some axis of abstraction over others, but there are different lenses you can put on things that may make you want to classify by different criteria.

For example, you might have a bunch of things, some of which: (a) can be rendered in some display - could be console, HTML, print output, screen, don't care; (b) can be serialized to a variety of media; (c) have some common configuration, that interacts with some configuration management system; etc.

If you try and shoe-horn these commonalities into a hierarchy, you end up with classes that advertise being able to do too much and need to have "not implemented" error conditions, breaking the Liskov substitution principle.

Interfaces are a way of breaking out. They're additive, rather than hierarchical, from the implementing class perspective.

The other big problem (a bigger problem IMO) with inheritance is coupling. I don't think there's any closer coupling between two pieces of code in an OOP system than inheritance. Changes in a base class can radically alter behaviour in all descendants. Depending on the implementation of overriding, descendant behaviour can be accidentally hijacked with no compile time or run time warning merely by updating a dependency. The API by which base class and descendant class interact is bidirectional, with the flavours of both library (you call them) and framework (we'll call you), and intermediate internal state when e.g. overridden protected methods are being called is usually sorely undocumented and liable to change.

Use composition for reuse and interfaces for polymorphism. These can do the same as inheritance and more, and they do it more cleanly. Reuse and polymorphism are orthogonal concerns that inheritance tries to fuse awkwardly together.

Try Go if you’d like a familiar language without the inheritance that you can pick up in an afternoon.

The first question should be whether we need hierarchical logic, or what hierarchical logic is supposed to be.

It's even harder to define (which might be why OOP is so popular --- it's easy to get dogmatic about "OOP is X", and the cargo-culters will pick it up and spread it like religion), but I'd say "be pragmatic and let it come naturally". Systems tend to naturally form OO-ish things even if they're not written in an OO language; the Linux kernel is one example. I think of OO as just another layer of organisation beyond functions and structures, arising from the desire to group related data and code together.

In my opinion we need look at bringing the relational model into code, not just data. OOP is too awkward for complex relationships. Or, at least making code more relational-friendly to avoid the O-R-Impedance-Mismatch: https://en.wikipedia.org/wiki/Object-relational_impedance_mi...

There's nothing particularly wrong with OO as a programming paradigm when used for the right purposes. It was originally designed for simulating real world systems and still works great for that.

Aren't most large systems organized in an OOP manner?