Why OO Sucks by Joe Armstrong<\/h1>\n
(Note<\/strong>: This is a copy of the original that used to live at http:\/\/www.bluetail.com\/~joe\/vol1\/v1_oo.html<\/em>)<\/p>\n When I was first introduced to the idea of OOP I was skeptical but didn\u2019t know why – it just felt \u201cwrong\u201d. After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like \u201cswearing in church\u201d. OOness became something that every respectable language just had to have.<\/p>\n As Erlang became popular we were often asked \u201cIs Erlang OO\u201d – well, of course the true answer was \u201cNo of course not\u201d – but we didn\u2019t to say this out loud – so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully<\/em>).<\/p>\n At this point I am reminded of the keynote speech of the then boss of IBM in France who addressed the audience at the 7th IEEE Logic programming conference in Paris. IBM prolog had added a lot of OO extensions, when asked why he replied:<\/p>\n \u201cOur customers wanted OO prolog so we made OO prolog<\/em>\u201d<\/p>\n I remember thinking \u201chow simple, no qualms of conscience, no soul-searching, no asking “Is this the right thing to do\u201d \u2026<\/p>\n My principle objection to OOP goes back to the basic ideas involved, I will outline some of these ideas and my objections to them.<\/p>\n Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. Why is this?<\/p>\n *Functions do things. They have inputs and outputs. The inputs and outputs are data structures, which get changed by the functions. In most languages functions are built from sequences of imperatives: \u201cDo this and then that \u2026\u201d to understand functions you have to understand the order in which things get done (In lazy FPLs and logical languages this restriction is relaxed).<\/p>\n Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function<\/em>.<\/p>\n Functions are usually \u201cunderstood\u201d by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2.<\/p>\n Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.<\/strong><\/p>\n Consider \u201ctime\u201d. In an OO language \u201ctime\u201d has to be an object. But in a non OO language a \u201ctime\u201d is a instance of a data type. For example, in Erlang there are lots of different varieties of time, these can be clearly and unambiguously specified using type declarations, as follows:<\/p>\n Note that these definitions do not belong to any particular object. they are ubiquitous and data structures representing times can be manipulated by any function in the system.<\/p>\n There are no associated methods.<\/p>\n In an OOPL data type definitions belong to objects. So I can\u2019t find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can\u2019t – the data type definitions are spread out all over the place.<\/p>\n Let me give an example of this. Suppose I want to define a ubiquitous data structure. ubiquitous<\/em> data type is a data type that occurs \u201call over the place\u201d in a system.<\/p>\n As lisp programmers have know for a long time it is better to have a smallish number of ubiquitous data types and a large number of small functions that work on them, than to have a large number of data types and a small number of functions that work on them.<\/p>\n A ubiquitous data structure is something like a linked list, or an array or a hash table or a more advanced object like a time or date or filename.<\/p>\n 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 \u201ctime\u201d object, where does this belong and in which object\u2026<\/p>\n State is the root of all evil. In particular functions with side effects should be avoided.<\/p>\n While state in programming languages is undesirable, in the real world state abounds. I am highly interested in the state of my bank account, and when I deposit or withdraw money from my bank I expect the state of my bank account to be correctly updated.<\/p>\n Given that state exists in the real world what facilities should programming language provide for dealing with state?<\/p>\n The global state of the system is carried into all functions and comes out from all functions. Mechanisms like monads (for FPLs) and DCGs (logic languages) are used to hide state from the programmer so they can program \u201cas if state didn\u2019t matter\u201d but have full access to the state of the system should this be necessary.<\/p>\n The \u201chide the state from the programmer\u201d option chosen by OOPLs is the worse possible choice. Instead of revealing the state and trying to find ways to minimise the nuisance of state, they hide it away.<\/p>\n I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.<\/p>\n This is is the real driving force behind OOPs.<\/p>\n<\/article>\n<\/blockquote>","protected":false},"excerpt":{"rendered":" These days it seems to be fashionable to say that “OO sucks”. Why OO Sucks by Joe Armstrong. We already read argumentations like this. That’s why the almighty Giuseppe Mazzapica titled one of his presentation What they told you about OOP is wrong This is also the case: dear Joe, your remarks are based on…<\/p>\nWhy OO sucks<\/h2>\n
Objection 1 – Data structure and functions should not be bound together<\/h2>\n
\n
Objection 2 – Everything has to be an object<\/h2>\n
-deftype day() = 1..31.\n-deftype month() = 1..12.\n-deftype year() = int().\n-deftype hour() = 1..24.\n-deftype minute() = 1..60.\n-deftype second() = 1..60.\n-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.\n-deftype hms() = {hms, hour(), min(), sec()}.\n...\n<\/code><\/pre>\nObjection 3 – In an OOPL data type definitions are spread out all over the place<\/h2>\n
Objection 4 – Objects have private state<\/h2>\n
\n
Why OO was popular?<\/h2>\n
\n