hierarchies and the real world

but don't always tell the whole story. ISA in particular carries meanings from the real world that don't always translate well in the software world.

Indeed. The real world is not tree-shaped for the most part when you get right down to it. Hierarchies may be a convenient mental model for analysis (for some people), but if you base your software model on it you will often be bitten in the long run. The bottom line is that almost nothing I can identify in the real business world is truly hierarchical in the longer run.

The biggest problem (but not the only) is that tree leafs assume mutual exclusiveness of some properties. If you subclass vehicles into cars and boats, you assume that something cannot be BOTH a car and a boat. But when marketing comes out with one you are hosed and have a lot of reshuffling of your methods and attributes that risk breaking existing code. Same with "data structures". If you use a class that is a "stack", you may later want to inspect or use the same data in non-stack ways. If you follow this to its logical conclusion, then you will end up pushing all possible data structure operations to the top of the hierarchy, and end up re-inventing a (non-relational) database. Using trees to manage or limit what attributes and behavior a thing can get is a dead-end.

The bottom line is that almost nothing I can identify in the real business world is truly hierarchical in the longer run.

Maybe you can't find them because you're blind. Let's see, the whole of the web is a Tree. The html that you are perusing is a Tree. The threads that you are responding to are a Tree. One need look no further than to the very concept of a Document to find them. Indeed, the Real World is chalk full of Trees.

What you actually mean to say is that (a). you don't think Types can be structured on a hierarchical basis - which is totally different to a rant that says that trees don't exist; and (b). you think a Relational Model more closely resembles the real world - not noting that relational design is a hard process that is fraught with many complexities.

If you subclass vehicles into cars and boats, you assume that something cannot be BOTH a car and a boat.

That's just a diamond shape of inheritance which is addressed by multiple inheritance. You don't give any cause to believe that an imperative scheme broken down along procedural boundaries is any more adept at sharing code betwixt the car data structures and boat data structures. You now have a car, a boat and a car-boat data structure or you have a massive data structure that handles every variation that you possibly throw at it.

Just because the methods get wrapped up in the object, this does not make it any more susceptible to problems of combining data structures. The only difference between what you propose and OO is that you don't encapsulate the methods within the data structures. Which means all your procedures have to cope with all the variations.

Welcome to IWETHEY!