EDIT April 22nd, 2019: After learning of Joe Armstrong's passing I came to think of this post again. According to some of the comments below, Armstrong's original post, already old when I wrote this, is not representative of the quality of his work. It would be a shame if it made the rounds in Twitter, Hacker News, and Reddit again.
Many programmers are fed up with dogmatic application of object orientation, which may be why Joe Armstrong's article Why OO Sucks has caused so much discussion around the Internet lately.
Armstrong claims that object oriented programming is bad. I'm no huge fan of OO either, but unfortunately Armstrong's objections against it are not backed by any clear reasoning. Let's have a look at his four objections.
Objection 1 -- Data structure and functions should not be bound together
Armstrong claims that data structures and functions are very different. Data structures just contain data, and don't do anything. Functions do stuff. This is obviously true, but Armstrong then goes on to claim that this is a reason to keep them separate. He doesn't give any explanation how he came to that conclusion.
For organizing your code, I don't see why it is a bad idea to to keep data structures and the functions that manipulate them in one place. Classes is one of the ways to do that. Modules is another. For example, it's not uncommon in C programs to keep declarations of data structures and functions that manipulate those data structures in a single header file. It's not called object orientation, but the basic idea is the same.
Objection 2 -- Everything has to be an object
Armstrong says:
Consider "time". In an OO language "time" has to be an object. But in a non OO language a "time" is a instance of a data type.
This doesn't make any sense. In many OO programming languages, a class is a data type, so an object is an instance of a data type.
Armstrong still has a point, but it's just in this objection's heading. He doesn't argue for it well, but in a pure OO language, you are forced to put all functionality inside objects. This can be more (Java) or less (Ruby) annoying.
Objection 3 -- In an OOPL data type definitions are spread out all over the place
If I understand this correctly, Armstrong prefers putting the definitions of all data structures in a limited number of source files. In OO you typically don't do that since in OO, you'd want to put the functions that operate on those data structures in the same file. That would make the file pretty big, which is impractical.
But this is just a matter of preference and programming style. Armstrong provides no argument as to how a different organization would make a programming paradigm suck.
He then writes:
In an OOPL I have to choose some base object in which I will define the ubiquitous data structure, all other objects that want to use this data structure must inherit this object. Suppose now I want to create some "time" object, where does this belong and in which object...
Just like the paragraph I quoted under Objection 2, this doesn't make sense. I don't have to create a base object to put my data structures in. An object is a data structure. And if you want to create a "time" object, just create a Time class. There is no need for inheritance. (Giving Armstrong the benefit of a doubt, perhaps he meant aggregation instead of inheritance. Inheritance is not as central to OO as many people believe, and there'd be no reason to use inheritance in the example that he gives.)
Objection 4 -- Objects have private state
Armstrong argues that state is evil, and that we should avoid state. OO's tradition of hiding state inside objects makes it less obvious that there are states involved, and hence more difficult to try to avoid them.
This argument is a good one, but it's not an argument against OO per se. It is possible to program in an OO way using only immutable objects, and avoiding state.
The basic idea of OO is that data and functions are bundled together, which is an idea that Armstrong seems to hold a grudge against (objection 1). But he gives no arguments as to why this is a bad idea.
There are several good arguments against dogmatic OO, but Armstrong doesn't seem to be the one to educate us about them.
Previous: Ludum Dare 23 postmortem
Next: Prioritizing Screenplain features