RE: "The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology taught to people in school." It'

RE: "The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology taught to people in school." It's worked fairly well for "isolated" groups of services, such as API's to file systems, network services, etc. Where it fails is domain modelling and any system or sub-system having more than a few entities. OOP doesn't scale when there is a large number of domain nouns and/or attributes involved. For example, OOP worked quite well for early and fairly simple GUI's. But when GUI systems and applications grew larger and more complicated, OOP GUI's turned into spaghetti. I believe something more like an RDBMS is necessary to manage large quantities of nouns and attributes so that one can slice and dice their particular view and grouping as needed for different tasks: query the parts instead of navigate a parts graph. You can navigate graphs like a cave explorer, but you can't easily say "show me all nodes (caves) with such and such...". Perhaps this is the "data orientation" you speak of. (I'm puzzled why in Java Swing the event handling code for a button click has to be fed into a "listener" instead of attached to the button object itself. The second is more logical in terms of thinking in the domain of UI's. Listener is an implementation detail that should be hidden away most of the time.) On a really small scale, trees and nesting work fine. On a medium scale graphs work fine. But on the larger scale, relational or something similar is a better tool. The hard part has been getting RDBMS to manage "blocks of behavior" well (events, snippets, functions, etc.).