Joe is wrong · Roads Less Taken
I just read Joe Armstrong’s old “Why OO sucks” article<br>, Joe Armstrong being the inventor of Erlang<br>. Granted, the article is from year 2000 I think, so perhaps I should cut him some slack… nah! :)<br>First of all - no, I haven’t programmed in Erlang (yet), but quite a lot of other programming languages. My favorite language is the grand father OO language - Smalltalk<br>. So sure, I am biased in favor of OO.<br>I have read other criticisms of OO, and various discussions about good or bad characteristics of OO in general and in specific OO languages… Sorry, this article is IMHO not among the good ones , and my feeling is that Joe wrote it quite quickly and with no real experience in programming in OO.<br>But I don’t intend to say his article “sucks” without arguing for why I feel it sucks :). And also, I am in great awe of the stuff<br>Erlang makes possible so I have great respect for Joe - but that doesn’t mean he can’t be dead wrong.<br>Let’s go through his article bit by bit:<br>“Objection 1 - Data structure and functions should not be bound together”
Link to heading<br>I quote:<br>“Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.”
Rereading that first objection I only see kinder garten explanations of what functions and data are. I don’t see any real serious explanation of why they couldn’t be combined into objects other than “because they are different”. That is not an argument.<br>It is in fact quite logical to group functions and data together into objects based on their interaction patterns, if for no other reason.<br>Let’s say we have data structures A, B, C and D. And we have functions q, x, y, z. If you start looking at what data is read and written by these functions you may find that q and x operates only on A and B, reading one and writing the other etc. So the functions and data structures form “natural clusters”, and usually these clusters are quite intuitively modelled as objects.<br>Putting them together creates a boundary around this group of data and functions - encapsulation. Sure, you may call that a “module” but an object is IMHO slightly different since objects have identity, a life cycle and we can hold them, send them around etc.<br>So in some sense objects can probably be viewed as modules but often more fine granular. And we can combine such “modules” into larger modules (since objects have identity and can be referenced etc) and we can create and kill them dynamically (life cycle).<br>If I were coming from a language with a well developed “module” concept I can definitely see this as just “another step” forward.<br>Another interesting fact with objects having a life cycle is that since an object contains data A, B, C and D we now easily can create a whole such data “group” by just instantiating this object. And we deallocate them together as a single entity too - manually or automatically. Again, quite natural.<br>So ok, I can go on and on about this but since Joe didn’t really give any arguments I will stop there.<br>“Objection 2 - Everything has to be an object.”
Link to heading<br>Now, being a Smalltalker I wouldn’t use the phrase has to be but I can clearly see all the benefits when the paradigm is really followed through in a pure way .<br>Ok, but let’s look at what Joe says. He points to an example - different datatypes for describing amount of time, or well, not “amount” but in fact partial pieces of points in time. Hour (of day), minute (of hour), year etc. Without knowing Erlang these data type definitions typically define ranges of integer values valid for these types. Anyway, then his main points are:<br>These data types can be used everywhere.
There are no associated methods.
The first argument is odd. Let’s look at Smalltalk (or any OO language), let’s say we have a class called TimeStamp. Or Date. We can instantiate these classes from anywhere in the system, there is no reason for classes to have any less (or more) scope than data types. So objects of classes can also be used “everywhere”.<br>The second argument is plain dumb (sorry). No associated methods? There are TONS of interesting behavior you can attach to these kinds of objects! For a true tour de force, just look at Chronos<br>for example. The fact that Joe can make such a claim is IMHO clearly showing that he really haven’t seen how a good OO library can work. Or I suspect ever programmed in an OO language in fact.<br>But if we disregard this bad example, going back to the original objection, I agree - everything does not HAVE to be an object. But a LOT of the problems in many OO languages can be traced to the fact that they still retain lots of “fundamental data types” that are not objects. And most of the modern OO languages get closer and closer to Smalltalk where...