Wednesday, February 11, 2009 6:00 AM
by
RickM
Why OO may not suck, or, Take a ride on the Falsus Omnibus
This post is in response to Joe Armstrong’s Why OO Sucks. While I feel that Joe’s post reads more like an sermon than a stream of rational thought, it does bring up a number of misconceptions I feel many people in the functional programming world share and which need to be discussed openly if it and the object oriented world are to come to terms and work together.
The main issue here is that, in the minds of many functional programming advocates, the concept of an object is inseparable from the amalgamation of 30 years of different, and sometimes contradictory, object oriented programming ideologies.
Perhaps they don’t understand that when binding these ideas together for the sake of argument they are simply constructing a straw man. Similarly, to say that we must either have all of the history of object oriented design or pure functional programming, is a false dichotomy. We can have either, neither, both separately, or any number of combinations of ideas from both groups.
Now, lets address each of Joe’s objections from a somewhat more moderate perspective.
In Response to “Objection 1 – Data Structure and functions should not be bound together.”
I disagree with Joe’s logic here. It does not follow that because functions and data structures are “different animals” that they should “not be kept in the same cage”. Wouldn’t having functions be first class citizens be locking them in the same cage with data structures as well? The fact that they do share some fundamental similarity is manifest in that most functional programming languages do not treat function and data structure in a fundamentally different way.
Also, I have seen no compelling reason as to why it is wrong to couple transformations with the data structure that they are able to be applied to. When transformations often have to be tailored specifically for a particular data structure, why would we not keep them strongly associated with said data structure.
In Response to “Objection 2 – Everything has to be an object.”
As I discussed in my introduction, this is simply not true in all languages which support objects.
In Response to “Objection 3 – In an OOPL data type definition are spread out all over the place.”
First of all, it should be immediately obvious to anyone who works on even medium sized projects that having many types defined in the same file is a very bad thing. The core of the issue is that it makes group collaboration quite difficult.
Secondly, any system that has ubiquitous data structures can’t be very large otherwise the namespace would become quite cluttered. In large systems this cannot be mitigated by simply saying “more functions, fewer data structures”.
Finally, to state that any object which operates on another must inherit from it is a completely incorrect statement. In the modern object oriented world it is common to have objects which exist solely to build, process or interface with other objects. Also, as I mentioned above, it’s entirely possible to have stateless objects which are simply data structures which are bundled with a collection of predefined transformations.
In Response to “Objection 4 – Objects have private state.”
First of all, state is not the root of all evil. While it may be harmful to concurrency and static analysis, there are many stateful algorithms which perform much better than their stateless counterparts.
Secondly, it’s entirely possible to have immutable objects. Perhaps in these objects some state is hidden for the sake of representing ideas in a simple manner, perhaps not.
Finally, as to information hiding in general, in large systems it’s very easy to be overwhelmed by the quantity of information. If you can say via testing “I can trust this structure over here” it means it’s entirely possible to ignore that and focus work on another piece of the system. It’s also important to note that functional programming languages often have information hiding systems of their own. In the most base case, calling other precompiled functions amounts to information hiding and comes along with all of the negative things stated in this section.
In Response to “Conclusion – Why OO was popular.”
It seems to me here that if you removed all instances of “It was thought” this would be a somewhat correct summarization.
In reality, the industry has been using object oriented programming for many more reasons than what has been listed here. A particularly strong reason is that it supplies an organizational framework for data structures and functions which simply does not have an equivalent in the pure functional programming world.
Conclusion
I must apologize to Joe here. I don’t intend to pick on him in particular. However, I had never previously seen a post in which the the most common misconceptions around object oriented programming were so plainly stated.
To say that the concept of an object and that the collections of ideologies used commonly to construct programs using objects are somehow inseparable is completely false. To further state that the only reasonable choice is to instead move to pure functional programming bears no additional truth. Yet they are both pieces of constantly perpetuated misinformation.
The fundamental idea that data and function can be bound for the sake of organization still holds and does not inherently violate any of the tenants of functional programming. In terms of the organizational structure of our programs we have gained much from objects. Why then should we abandon them without sufficient reason? It seems to me that it would be a mistake to dismiss all of what we have gained for baseless ideological reasons alone.