Hacker News new | ask | show | jobs
by pestaa 4134 days ago
You are right.

http://programmers.stackexchange.com/questions/99166/dijkstr...

Although, OOP is still a mess.

1 comments

It's hardly any kind of "mess". It's the most practical and intuitive to reason about choice for a significant amount of work that needs to be done. FP excels at some cases but not all of them. Contorting all of my OOP code into a functional structure would be a nightmare.
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.

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.

Agree, most of the corporate "OOP" code I have seen, at the best of the cases, handle modularity. Everything else is kludge.
And it's not as if you need class-based OOP to have modularity, for that you just need modules.
> the most practical and intuitive

What is intuitive to one is not necessarily intuitive to all.

True. Does this have anything to do with the way programming is taught, most of the times starting with imperative then with OOP ?
I think that there are objective measures of complexity. So there are objective measures of simplicity.

ideographic writing is more complex and less composable than phonetic writing and yet can express the same ideas.

Subjectively, a chinese can understand Chinese ideograms while maybe he find written English difficult to understand. But a Chinese would learn phonetic writing in less time than ideographic writing and would be capable to express complex ideas using the most composable writing system in less time, no doubt.