There is more than meets the eye in OO. First, most languages aren't doing OO the way it was described by Alan Kay who coined the term. What we have are data

There is more than meets the eye in OO. First, most languages aren't doing OO the way it was described by Alan Kay who coined the term. What we have are data structures with procedures that invoke other procedures in data structures. That's a long way from independent units sending messages to each other. REST on the web these days may be closer to that initial intent. Not that it means anything special, but I've been busy with this "Object" thing since 1990, trying to figure out what it meant exactly. C++ (Symantec C++, MS Visual C++ with COM/ATL, Delphi, Tcl with Xotcl, Java with the dreaded EJBs shipwreck, Smalltalk, R, C (including Tuxedo services), Assembly, Javascript, and other languages like Clipper/xBase have been used to deliver client solutions. A couple of the are not OO at all. Still they worked too. For the record, I've also given OO related trainings to more than 2000 people over the years (language side, analysis side, system design side) and seen people "getting it" or not. I've been involved in UML (and OMT/Booch/... before that). At this point in time, a lot of that boils down to being able to partition a system properly based on responsibilities and the team that is available to build the system. Fred Brook was right, there is no silver bullet. "OO" designs were quite apt to adjust to changes that were quite probable. But some changes just made them break. For some systems, the OO approach was really good for remembering what was done. I remember being called to fix an issue in a system that had been running in production for, like 13 years (it was C++). It was easy to figure out how things were laid out, as the pieces were still identifiable. One lesson is that objects shouldn't be too fine grained. Too many objects and you get the "ravioli" effect. Good architecture and good coverage of key concerns is what matters. Once this is done, technology can be bent to do one's will. I do have a personal affinity to objects but with functions and closures, one can get other ways of thinking. But there is something that has been all wrong for years, namely the fact that a lot of OO languages required to have hierarchies for polyphormism to work. And that's just wrong, and that's why I like Smalltalk for example with the messaging at the core. That's what made Tuxedo apps successful for transaction processing. Messaging, async, ability to decouple. That is more key than structures. And that's been lost for a long time. Javascript gives more in that regard, despite it being quite a kludge of a language. But it is flexible and has closures, more than a lot of "OO" languages. I don't thing OO is what made Java successful as OO designs in Java are quite poor and over complicated. Spring gave some sanity back but the core thing is that Java has libraries for a lot of things. Not that it is OO. My take is that OO is going to be less of the dominant way, and we are entering the age of the polyglot programmer.