This article is easier to appreciate if you view it as a window into the thinking style of a another programmer, rather than an actual argument about what is right or wrong. (That is, patch your local branch of the headline to "Why OO Sucks For My Way Of Thinking".)
The impressions I get are that Armstrong likes to stay close to a core set of raw data structures; he's more about the flows than the stocks; he finds delegation and specialization more frustrating than helpful; and he would rather build a combustion engine than an office building.
(He's probably an ISTP personality type at work but has put on his ISTJ hat for the purpose of writing this article.)
Yeah, I saw the other comment clarifying that. (And if it were a random dude ranting, I wouldn't devote much effort to understanding his way of thinking. It's the earned credibility from Erlang which got me -- an OOP fan -- past the headline to try to see through Armstrong's eyes.)
I think an unacknowledged bias in his points is that having the data entangled with the functions is especially problematic for Erlang-style concurrency.
I agree with him that having the most important data structures of the program scattered all over the place makes it needlessly difficult to understand, but I think many of the major problems with OO actually come from overusing inheritance. Compounding this, OO design can be very brittle: It works in theory, but in practice, it only takes one person who doesn't really understand OO (or one person having a dumb day) to screw up the whole design in subtle ways, and there will always be someone on a team who isn't quite up to speed. Worse still, when OO breaks down, it tends to gradually drown the project in busywork ("...if we just move this from this class to this class and rewrite a bunch of delegation code...") rather than just being an obvious dead-end.
It seems like focusing on interfaces rather than a hierarchy of classes cuts out many of the problems with inheritance. Something like ML functors or Haskell typeclasses seem like a good fit, as well. (I haven't tested those on any especially perversely organized projects yet, though. The measure of a technique is whether it still works on hairy stuff, not whether it works well for idealized examples.)
Oh - OO is pretty vaguely defined; I'm talking specifically about C++/Java-style class-based OO. (I haven't ever used CLOS-style OO, and prototype-based OO is probably vulnerable to the same pitfalls as class-based.)
Also, while this article by Clay Shirky (http://www.shirky.com/writings/ontology_overrated.html) is more about categorizing information, it demonstrates very nicely why trying to pigeonhole everything into a hierarchy of classes doesn't always work in practice. (I posted it to the front page, since it hasn't been yet...)
The impressions I get are that Armstrong likes to stay close to a core set of raw data structures; he's more about the flows than the stocks; he finds delegation and specialization more frustrating than helpful; and he would rather build a combustion engine than an office building.
(He's probably an ISTP personality type at work but has put on his ISTJ hat for the purpose of writing this article.)