Abstraction is a good thing, but what I'm talking about here is object-oriented programming. An "object" is something of which one has incomplete knowledge. OOP

Abstraction is a good thing, but what I'm talking about here is object-oriented programming. An "object" is something of which one has incomplete knowledge. OOP is, I would argue, about managing incomplete knowledge, on the (correct) assumption that if systems get large, it will be inevitable that people don't understand all the details of what they're working with. Good abstractions deliver a lot of value. Files and sockets, for example, should be treated as objects, because the client should (usually) be agnostic of how the things are actually implemented. So OOP isn't all bad. What's messy is a paradigm that gives an unbounded right to inject complexity. Programmers don't have enough autonomy in most corporations to do things right, so the result in most cases of Brownian-motion requirements is an increasingly gnarly pile of hacks. What Haskell does well (being both functional and statically-typed) is punish that style of development while it occurs, making it so that the kludge isn't always the path of least resistance.