OO is applied for the wrong domains. A typical web app with a database back-end is probably the worst offender. Modelling your data with OO, fitting it someho

OO is applied for the wrong domains. A typical web app with a database back-end is probably the worst offender. Modelling your data with OO, fitting it somehow (ORM == OMG) into database tables and then use some annotation magic to turn those objects into JSON towards the frontend. Nothing there makes any sense whatsoever. I built several of those and used terrible ORMs. They are hard to change. They are hard to reason about and they consume massive amounts of memory as each transaction creates fresh sets of objects - because we can't share data between threads simply - we throw those objects away again. Gone is this whole ideal notion of objects being their own little agents, sending friendly messages between each other. And the fact that message passing is not well-defined in a concurrent context in most OO-languages puts the icing on the cake. (i.e. objects can receive messages (i.e. calls) from any thread at any time and need to deal with it. Most of the OO code you wrote today cannot.