> That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late b

> That's not a direct result of OOP. It's actually the core definition of objects. Objects are entities supporting open recursion, self-polymorphism and late binding. There is a difference between "having type-classes" and "having object as a core formalism of computation" > Languages can have Languages can have objects, or actors, or other entities alike. This doesn't mean it's prudent to design your code around the idea of message-exchanging FSMs. Sometimes at some scale objects or actors are useful. > And it's not like the problem magically goes away for procedural code. This is empirically not true, and the frameworks example is the best proof of it. In languages like (functional) Scala, Go, OCaml, libraries do compose well enough, and gluing them is cheap. Any hardcore OOP language eventually brings frameworks like Spring, Rails, etc, because gluing objects is expensive, and for no reason, if functional/procedural alternative is so much cheaper. Even natural transformations between monads are very cheap compared to objects' composition.