"The people who originally came up with OOP knew what they were doing. The inspiration [of OOP] was the cell, which hides immense mechanical complexity behind a simpler interface..."
I think you are making two mistakes:
(1) Assuming that any good API/interface must be object-oriented; and
(2) Assuming that, when using object-oriented programming, that good APIs/interfaces come naturally.
Cells are obviously a very successful kind of module. What does that really mean? It's just an analogy. Erlang, the "non-OOP" language under discussion, seems to resemble cells at least as well as "OOP" languages (perhaps more so, because you don't have to synchronously wait for a response for every interaction).
This is part of the reason that people call erlang an OOP language. So clearly there is a major confusion over terms here, because the creator of erlang didn't originally consider it to be OOP.
OK, so let's assume that we're actually talking about something that is as non-OOP as I can imagine: haskell. Let's also assume that haskell doesn't resemble cells as much as OOP does. There are still problems:
* Many interfaces in haskell are very well-designed, so it's hard to argue that OOP has a monopoly on good interface designs
* It's not clear that the goals you mention, such as unexpected dependencies, are actually reduced by using OOP.
* It's not clear that a superficial similarity with cells really translates to anything meaningful. If nothing else, evolution of cells takes place on million-year timescales, and doesn't drive toward any one particular kind of outcome other than self-perpetuation; which are not a good set of properties when it comes to project management.
You are projecting those assumptions on the original poster, and to some extent the smart folks that pondered the cell analogy in the first place.
Neither argue that FP can't be built modularly with a wonderful structured API. OOP, conceptually, is simply one way to accomplish that goal. FP is another.
In both cases, the underlying philosophies are sound, it is the humans that implement the solutions that fall well short of the mark.
He opened up the response with an analogy about cells.
For an analogy to have any use at all, it must illustrate a contrast between two relevant ideas.
The article is entitled "Why OO Sucks" and written by the author of Erlang.
I "projected" that the comment to which I replied was defending the non-suckiness of OO by using the cell analogy to contrast with erlang. Are you saying that was a leap?
What you are saying makes sense: there is more than one useful model. But that point should be made in the context of Joe Armstrong's specific criticisms; not claiming that OOP is as modular as a cell and erlang is not.
I think you are making two mistakes:
(1) Assuming that any good API/interface must be object-oriented; and
(2) Assuming that, when using object-oriented programming, that good APIs/interfaces come naturally.
Cells are obviously a very successful kind of module. What does that really mean? It's just an analogy. Erlang, the "non-OOP" language under discussion, seems to resemble cells at least as well as "OOP" languages (perhaps more so, because you don't have to synchronously wait for a response for every interaction).
This is part of the reason that people call erlang an OOP language. So clearly there is a major confusion over terms here, because the creator of erlang didn't originally consider it to be OOP.
OK, so let's assume that we're actually talking about something that is as non-OOP as I can imagine: haskell. Let's also assume that haskell doesn't resemble cells as much as OOP does. There are still problems:
* Many interfaces in haskell are very well-designed, so it's hard to argue that OOP has a monopoly on good interface designs
* It's not clear that the goals you mention, such as unexpected dependencies, are actually reduced by using OOP.
* It's not clear that a superficial similarity with cells really translates to anything meaningful. If nothing else, evolution of cells takes place on million-year timescales, and doesn't drive toward any one particular kind of outcome other than self-perpetuation; which are not a good set of properties when it comes to project management.