"Object-oriented programming" is like "God" or "feminism"-- pointless to debate until you define terms, and ranging from the agreeable/probable to the ridiculous depending on precisely how terms are defined.
The original idea was that, when a piece of software becomes complex, it should be factored out and given a simpler interface. Alan Kay used the cell as a metaphor: it's a complex machine that interacts with the rest of the body using a simpler language of chemical and electrical signals. And that turned out to be such a good idea that you see it even in non-OOP programming tools. Haskell's type classes are a comparable idea. FP picks the best noun (immutable data) and verb (referentially transparent function) for most purposes (of course, the world is stateful and there's some debate over how to manage that). At scale, we also have to deal with the "adjective problem" because we want to be able to code against abstractions rather than (less stable) implementations.
For example, it's a good thing that languages support a File object (an abstraction that Unix is built on) that allows application programmers to avoid having to know what kind of "file" they are dealing with. It's nice being able to use the same language (open/read/write/close) regardless of the physical machinery that the file lives on.
The problem is that corporate OOP has become complexity for it's own sake. Alan Kay wasn't saying, "Go out and design massive, complicated objects". He was only proposing strategies for when complexity became inevitable. Unfortunately, Business OOP (a bastardization of OOP, which had some good ideas at its core) rewards complexity, and you have "enterprise architects" who can't code but are paid to generate massive tangles of lines and boxes.
I think the blessing and the curse of OOP is that is actually pretty good for simulation (SIMULA got it right I guess :) ), so what you usually have is a program that's a simulation of a process. Even the standard OO modelling techniques encourage simulation of "real world" entities. But that direction doesn't lead to the most efficient,composable , or easy to reason abstractions.
It doesn't help that the main abstraction mechanism in OO (superclass/subtyping) is problematic enough that even most people recommend moderation in its use.
The actual big thing about computers (Turing Machines) is that they let us simulate things, including other computers. But, once we recognize the fact that some computers are “better” than others, we then realize that the amazing thing about computers is that they allow us simulate better computers, it's just hard to do so.
Thus, the blessing and curse of OOP, respectively, is that it’s ideal for building simulations (the actual point of computers), but also makes it really easy to simulate a worse computer on top of better ones. So, the real tragedy of “Enterprise” OOP is that it basically encourages programmers to first simulate lame computers (e.g. by building frameworks), and then write programs for them.
The original idea was that, when a piece of software becomes complex, it should be factored out and given a simpler interface. Alan Kay used the cell as a metaphor: it's a complex machine that interacts with the rest of the body using a simpler language of chemical and electrical signals. And that turned out to be such a good idea that you see it even in non-OOP programming tools. Haskell's type classes are a comparable idea. FP picks the best noun (immutable data) and verb (referentially transparent function) for most purposes (of course, the world is stateful and there's some debate over how to manage that). At scale, we also have to deal with the "adjective problem" because we want to be able to code against abstractions rather than (less stable) implementations.
For example, it's a good thing that languages support a File object (an abstraction that Unix is built on) that allows application programmers to avoid having to know what kind of "file" they are dealing with. It's nice being able to use the same language (open/read/write/close) regardless of the physical machinery that the file lives on.
The problem is that corporate OOP has become complexity for it's own sake. Alan Kay wasn't saying, "Go out and design massive, complicated objects". He was only proposing strategies for when complexity became inevitable. Unfortunately, Business OOP (a bastardization of OOP, which had some good ideas at its core) rewards complexity, and you have "enterprise architects" who can't code but are paid to generate massive tangles of lines and boxes.