[michaelochurch]

Upvoted, though I disagree, because I hate when people use downvotes for quality content they disagree with, and you don't deserve to be grayed out.

"Object" often means "thing of which I have incomplete knowledge". When you have an Object, you've given up on reasoning about it from axiomatic principles or deep knowledge, and you're looking at it holistically alone.

Sometimes, that's just fine. The Unix File concept is a well-designed object, because you can use the read and write system calls without having to know whether it's a regular file, a socket, a tape drive, a memfile, or something else.

While working under incomplete knowledge is sometimes necessary, it's never the ideal. You can use Alan Kay's original OOP principles when software reaches a certain level of complexity, but shouldn't orient your programming around incomplete knowledge or unmanageable complexity. The problem with corporate OOP is that it enables the imprecision-of-thought of technically incompetent software managers and "enterprise architects" who are better at managing up than at solving technical problems.

In fact, Dijkstra spells out the problem with corporate OOP in two words, as quoted in the OP: complexity sells. Complexity + imprecision-of-thought = disaster. And a major reason why top-5% programmers love Haskell is because it simply blocks the imprecision of thought that characterizes typical, business-as-usual, mediocre corporate software development.

[agocorona]

Well though. I agree with that. The good abstraction is more about interfaces rather than objects. I complain more about the primitive use of objects as message receivers" with state. That was at the moment the best solution available for the problem of managing events. But this idea of inversion of control pervaded all the industry in perverse ways Even where it was not necessary. The corporate OOP is mostly a consequence of that.

This is just random thoughts and there is much more to say. Neither I pretend to tell that OOP is wrong. What I say in the article is that the deconstruction of the recipe that OOP naturally demand is very painful and has too many drawbacks, and can be avoided with the right tools.

[__Joker]

Agree, most of the corporate "OOP" code I have seen, at the best of the cases, handle modularity. Everything else is kludge.

[kyllo]

And it's not as if you need class-based OOP to have modularity, for that you just need modules.