8 ms·

Why OO Sucks

85 points by ananthrk 18y ago

Kototama 18y ago
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. Obviously not if you use composition and if some objects are just your wrapper for your data structures.
swombat 18y ago
Summary: I don't understand programming much, I don't understand OO, I don't know how to do OO properly, and so I think OO sucks. This article is Not Even Wrong. It's not close enough to even being wrong to warrant a thought through response. The author needs to go and learn how to do OO properly before making wild declarations about "Why OO sucks". ================ Edit: worth clarifying this as I've just realised that this guy is supposed to be the author of a programming language (quite worrying if he is!) As I said, this is too far from even being wrong to be worth really debating point by point, so I'll just poke a few holes to demonstrate that I'm not just flaming: 1) functions and data structures belong in totally different worlds Anyone who's even glanced at SICP knows that the distinction between data and functions are vague at best. Certainly they are tightly coupled concepts. ------------ 2) 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. How does that have anything to do with the age of the captain? Not only the author's main point doesn't make sense, but he feels the latitude to make tangents about unrelated things that don't really have an impact on his obviously controversial main point. -------------- 3) The "time" example that he gives... In this example, he basically creates an ad-hoc object made of methods that return data. The only difference between this and proper OO is that this structure doesn't benefit from all the advantages of OO. But it's still a tightly coupled structure made of data (the values) and functions (the methods to access those values). -------------- 4) In an OOPL data type definitions belong to objects. So I can't 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. So now language design should be driven by whether you have a decent editor that allows you to manage more than 1 file? Seriously, the "Everything in 1 file" anti-pattern is not even worth arguing about... When someone makes such a dumb point, how can you take the rest of the article seriously? -------------- I could go on, but I think I'm proven my point. Either this article was not written by Joe Armstrong, or it casts severe doubt on the sanity of Erlang, or he's written it to troll the OO community.
- jwilliams 18y ago
  Agreed. Most of his reasons are straight tautologies - "Here is my definition of XYZ" - then, see how coincidentally that definition clashes with OO?
- ananthrk 18y ago
  The said author is Joe Armstrong (of Erlang fame)
  - swombat 18y ago
    Yep, I just got that and updated my post to include argument supporting my point. Inventing a language doesn't preclude you from being sorely wrong.
    - ananthrk 18y ago
      Agreed. Not knowing the author is all the more better as the response will be not clouded by "OMG, he created Erlang :)"
      - jmtulloss 18y ago
        At the same time, Erlang handles its problem domain like a champ. Knowing that this was written by Joe Armstrong, you can see that he might be approaching this from a different angle than others, even if he is lacking in eloquence here. I would tend to agree that OO is pretty bad for highly parallel programs, which makes this all seem a bit more reasonable.
- gaius 18y ago
  Meanwhile Erlang is dominating C++ in its niche. Coincidence?
  - swombat 18y ago
    I haven't heard of any games or embedded systems written in Erlang...
visitor4rmindia 18y ago
IMHO this is a pretty poor rant. Let me argue each point: * Data structure and functions should not be bound together In some cases encapsulation works really well. For example GUI elements. It is less true for "process-oriented" components. But the arguments he makes don't seem very well thought out. * Everything has to be an object I actually agree here. To my mind, the biggest problem with OOPS is that is slowly devours all other concepts until we are left trying to force-fit all problems into the OOPS mould. * In an OOPL data type definitions are spread out all over the place This just ignorance. * Objects have private state This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters. * Why is OOPS popular? Because it makes it easier and safer to get programmers working together as a group. The vocabulary of available objects is a simple and somewhat elegant way of communicating. (EDIT: Corrected layout.)
- jwilliams 18y ago
  He probably has a point in some ways, but some of the points seem so bad they are almost impossible to rebuff - e.g. functions are functions, data is data, therefore they must be separate? Additionally, he's run up against the pitfall with OO - it actually lacks a definition. It's got lots of dimensions and facets, and each implementation interprets these in it's own way... e.g You could argue that SmallTalk's message passing metaphor was the precursor to Erlang's model.
  - visitor4rmindia 18y ago
    Actually the first line sums up the problem with this article: >When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". It's more a personal rant than a well thought-out article.
    - access_denied 18y ago
      What is wrong with a personal rant? Does every writing needs to be a well thought-out article? Discussions. Essay. Opinions. Why not?
mariorz 18y ago
"Data structures just are. They don't do anything. They are intrinsically declarative. 'Understanding' a data structure is a lot easier than 'understanding' a function. " I'm possibly damaged from a few years of OOP but how do you separate a data structure from its functions? e.g. How can a B-tree mean anything separate from its search/insert/delete operations?
- visitor4rmindia 18y ago
  In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself. For instance most examples on the net just assume keys to be long numbers but that is obviously insufficient for an actual application. Keys could be 20-bit hashes, strings, floats, doubles etc. The same applies to a lesser degree to the offsets (at leaf node level) and any embedded values. Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects.
  - mariorz 18y ago
    In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself. I'm confused, you store values in the tree but in itself it is not a data structure? Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects. I see a B-tree as a data structure not an object per se, I still don't see how it would mean anything without its operations.
    - visitor4rmindia 18y ago
      Let me try and give an example. Let's assume we are modelling a non-leaf node which contains long keys and long offsets. We can do it in any of the following ways: |offset0|key1|offset1|key2|offset2|key3|offset3......| OR |key1|key2|key3...|offset0|offset1|offset2|offset3...| OR |offset0|offset1|offset2|offset3...|key1|key2|key3...| OR |count|key3|key1|key7...|offset0|offset1|offset2.....| <== Binary search-able keys In all of these cases, the data structure is different but the basic B-Tree algorithm remains the same. You can implement the algorithm once (using templates (C++), macros (C), or a weakly typed language (Lisp/Scheme)) and re-use it with any and all data structures that come up later. EDIT: Forgot offset0
gojomo 18y ago
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.)
- silentbicycle 18y ago
  (He's the main designer of Erlang, FWIW.)
  - gojomo 18y ago
    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.)
    - silentbicycle 18y ago
      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.)
sunkencity 18y ago
If people get angry while reading this article, there must be some truth in what he says. Dissing OO is still swearing in the church. I programmed for a long time not knowing OO and it was fine, there are other ways of encapsulation/isolation of code that works just as well. I don't really see that there's a big difference, and there's a certain element of religion about OO vs Functional. Both have their own merits in different types of applications. Still it's nice with someone who stands up for the functional approach.
- barrkel 18y ago
  No anger here; just unmoved.
- jff 18y ago
  OO and Functional are not the only two styles of programming out there. There's actually Functional and Imperative (and maybe others?), with OO being an additional concept that gets tacked onto both functional and imperative languages.
  - ricky_clarkson 18y ago
    OO exists on top of the imperative paradigm, never the functional one. If you disagree, please define OO.
    - parenthesis 18y ago
      Common Lisp is a multi-paradigm language, but its OO features can be used in a functional style.
    - hassy 18y ago
      1. OO has no precise and universally accepted definition. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html 2. Parameterized modules in Erlang can be seen as a form of lightweight functional OOP. http://www.lshift.net/blog/2008/05/18/late-binding-with-erlang http://www.lshift.net/blog/2008/05/18/late-binding-with-erla... http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf
jonke 18y ago
If the people who got upset of the article should unite of what OO is we could read that one comment. In the meantime read http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html Be neutral. Think. Could Joe have some valid arguments ? As someone said, patch your brain into Net Neutral.
niv 18y ago
then what about abstract data types?
time_management 18y ago
OO concepts are occasionally cool and useful. Note the use of the word occasionally. 90+% of the time, when you create an object, what you really want is a struct/record. Most methods should really be static. Most of the power that does come from OO comes from its ability to foster a hierarchical type system in an extensible way. OO smells like something that was invented to give "business" types the illusion that they can understand code without reading it in detail. "This is 'like a' Chair."
- narag 18y ago
  90+% of the time, when you create an object, what you really want is a struct/record. I don't. I've been fortunate enough to use a language that doesn't force the "everything's an object" mantra. The two real advantages of OOP (from my POV anyway) are encapsulation (minimal interface) and convenient syntax: the first parameter turns to be a prefix so it resembles human language, a question of usability really.
  - silentbicycle 18y ago
    Encapsulation can also be handled well at the module/package system level, though. (The package system in OCaml has some particularly interesting features.) The latter is a mixed blessing. It's often very convenient, but sometimes there isn't a clear answer which object should be the primary one in a binary operation. (This is particularly troublesome with non-commutative operations.) Lua's syntactic sugar for this ( obj:method(args) vs method(obj, args) ) seems like a good balance; it's explicit that it's just sugar for convenience, but you aren't required to use it.
    - narag 18y ago
      Encapsulation can also be handled well at the module/package system level, though Yes, it's more or less the same, but you can define public and private parts for individual objects. The good part of encapsulation is separating interface from implementation: you can publish a data type without giving access to its innards. sometimes there isn't a clear answer which object should be the primary one in a binary operation I really haven't found it to be a problem in practice.
jcromartie 18y ago
I have to say that I agree with this only as long as we're talking about languages that don't have excellent OO capabilities. C++, Java, C#, and most others failed to impress me with their approach to OOP. But then I got to work in Smalltalk, and it dawned on me: "this is what OOP is supposed to be like."
- access_denied 18y ago
  Would you say Objective-C has it "right"? In other words, should a beginner to OOP (me) learn Smalltalk or Objective-C (first)?
  - jimbokun 18y ago
    If you want to learn maybe the "purest" implementation of object oriented programming, learn SmallTalk. Everything in SmallTalk is an object, and objects communicate exclusively by sending each other messages. Almost every other programming language has some non-OO "escape hatch," like direct access to data fields or primitive (non-object) data types. Use Objective-C if you want to program the Mac or iPhone in the near future. It largely copies the SmallTalk model, but grafts it on to C, which means that you can still do all the non-OO things that C can do. This engineering compromise seems to have turned out to be a pretty good design choice, but perhaps not as aesthetically pleasing as the "pure" SmallTalk design.
    - jmtulloss 18y ago
      I would also add that Smalltalk might be more frustrating to do "cool things". It's a gratifying language to learn as an experienced developer, but for somebody just starting out, the fascination comes from the end result, not the elegance of getting there. I know when I was first starting out, I wasn't capable of writing an elegant line of code. I barely am now, but at least I can recognize it when I see it.
trezor 18y ago
Knowing how many fuckups and bugs which have happened trough the years because of incorrect handling of times and dates, I can't believe he advocates that they should be "ubiquitous ... data structures representing times (which) can be manipulated by any function in the system." Obviously the thought of a one single encapsulated DateTime class which manipulates time and dates (correctly) for us is a horrible idea.
iamwil 18y ago
As a disclosure, I've been using Ruby for the past three years, and it's about as object-y as you can get. However, Ruby opened my eyes a bit to exploring other languages. Point is, as I started looking at other languages in depth, I found myself using objects a little bit less, especially in the design pattern sense. Some problems in the traditional 23 design patterns just disappear in dynanmic languages. After programming in Lua and Javascript, I find objects nice, but optional. Nowadays, I sort of just use classes to scope and namespace. I keep state in classes when it makes sense. To counter the point about state, Erlang programs do have state. They're just contained locally within a function. Since Erlang has tail recursion, you just call the same function recursively and pass the state variable you want to keep at the very end of the function for the lifetime of the program. Because it's tail recursion, there's no stack overflow. Also, Erlang threads can keep 'state' inside of the Mnesia database that comes with Erlang. State is only evil when it's shared. Because state is contained locally in a function, a single Erlang thread can do whatever it wants, whenever it wants with those variables. Threads communicate through message passing. Therefore, no need for locks, mutexes or semaphores. Along with the low overhead of thread creation (~300 bytes) they're part of the reason why Erlang has great concurrency properties.
TweedHeads 18y ago
Humans walk(), eat() and rest(). Invoices don't do shit. We need both.
- visitor4rmindia 18y ago
  If I understand you correctly you're saying something like TweedHeads.walk(), TweedHeads.eat() and TweedHeads.rest() make it sensible to define Human as a class. But then how would you attach makelove() or fight() or discuss() to a single Human? When do we use TweedHeads.discuss(visitor4rmindia) vs visitor4rmindia.discuss(TweedHeads)?
  - ivey 18y ago
    It took me a minute to realize that TweedHeads was an object and not a class.
    - MHollender 18y ago
      I figure humans are best modelled as singletons, each being one instance of his own class... (This is why prototype-based OO would sometimes be more useful)
  - MHollender 18y ago
    (Python) TweedHeads.Say("something", visitor4rmindia.Listen) visitor4rmindia.Say("something else",TweedHeads.Listen) The Say method takes 2 parameters, what is said in a string, and a reference to the listening method of the partner. The Say method will first write into the it's private log "I'll remember for a while, I said to {listenmethod.im_self}: something" and do perhaps do some other stuff, and then call the referred Listen method passing in the "something" as a parameter and also passing self as a parameter, to let him know who said it to him. The Listen method of that object will write into it's own private log "I'll remember for a while: this guy {the passed-in self} told me something", and then perhaps do some other stuff. Of course this is functional/OO, and a pretty awesome kind of OO, it being Python, not just basic mainstream OO.
  - kilowatt 18y ago
pj 18y ago
I won't go so far as to say OO sucks, but I have noticed in my own code, that I have tended to use OO concepts a little bit and functional concepts a lot. Over time, I'm using less and less OO and more and more functional, so... that tells me OO wasn't all it was cracked up to be. The biggest problem I see with OO is that it doesn't map well to relational models and OO databases aren't that popular.
charlesju 18y ago
I think Alan Kay just cried a little inside.
c00p3r 18y ago
Programmers are talking about ideas, while coders are talking about tools. =) I'm personally prefer the description of mr. Booch - OOA/OOD/OOP is the way to manage the complexity of a problem. Unfortunately the rest of his book is an advertisement of the RUP and UML - yet another tools.
jonsen 18y ago
Von Neuman architecture sucks. From our educated and elevated point of view I think we can all agree on that. At least if we transcribe to "programming in machine language sucks". Perhaps one day we may elevate to agreement on "OO architecture sucks". OO is a successful technology measured by what has been accomplished with it. The von Neuman architecture is even more successful. The one and only architecture behind all general purpose computers. But no sane programmer would touch machine code directly. I have always thought that OO was wrong, in some sense at least. But I have to touch it. There is no higher and better level. There are alternatives but on the same level. So they suck in their own ways. I remember when I started forming my mental pictures of what programming in the large was all about. How to think about it. How to structure it in my mind. I read Object-Oriented Modeling and Design by Rumbaugh et.al. Even if the authors didn't succeed in explaining it fully, I got the vivid impression, that they wanted me to believe, that a computer model should be structured along three dimensions: data, functionality and events. A space with a recording axis, data, an activity axis, functions, and a time axis, events. Though a somewhat fuzzy picture, I "saw" these three dimensions as orthogonal and of equal importance in structuring and building the complex structures called programs. I find OO to intermingle the data-function-plane but leaving timing in the cold. A skewed space. I'm looking forward to the tools and technology, that will support my clean and "right" design model in a non-skewed concrete "code" space. Well, if they ever arrive, I might then have an even better mental model and find my self stuck with the new and better but sucking tools.
- jmtulloss 18y ago
  I'm sorry, this is way too thick of a block for me to read through. If you want a serious discussion of your idea, you might want to lay out your argument more carefully.
schtog 18y ago
I always thought that OO encourages not rigorous abstract thinking but fuzzy everyday thinking with arbitrary definitions.
msluyter 18y ago
I'm seeing a trend here: 1. X used to be regarded highly but turns out to be imperfect or suboptimal for certain problem domains. 2. Write "why X sucks" blog post. 3. Profit!
atlei 18y ago
Erlang is a functional language specially designed (and suitable) for concurrent programming. His rant is partially correct (at best), especially looking at OOP from a functional programming point of view. However, developers in the real world who doesn't focus on concurrent programming have different needs. I'll comment his objections from a C++ perspective (which is a multi-paradigm language, not purely OO): Objection 1 - Data structure and functions should not be bound together - you are free to store all your data structures in a single file, and access them from anywhere. However, using classes will let you hide some of the data structures which are not necessary globally, reducing the cognitive load. Objection 2 - Everything has to be an object - Not in C++. You use classes where appropriate, and ordinary functions elsewhere. I agree that everything shouldn't be an object. Objection 3 - In an OOPL data type definitions are spread out all over the place. - similar to objection 1. You CAN store all definitions in a single include file, but for large projects this can be a LOT of data definitions, where many/most of them are only relevant for parts of the applications. Hiding data definitions in separate classes will make it easier to focus on the RELEVANT data depending on which class/function you use. Objection 4 - Objects have private state. - again, similar to 1 and 3. "State is the root of all evil". If you store all data in a single file, then you have one giant global mess. By assigning them to a class, you clearly state the responsibility and scope of the variables. A private state is nobody's business but the class. You don't HAVE to have private state for objects,but then you either need to pass all data to each function, or use global variables instead. For Erlang (functional programming) these objections make (some) sense since you DON'T want any state whatsoever to facilitate concurrency. However, saying that OO sucks is stupid, and the four reasons for why OO was popular is not even worth responding to. I don't think functional programming will become more popular due to this rant....
jrockway 18y ago
Objection 1 - Data structure and functions should not be bound together This is not true of "OO", it's just true of OO in languages like C++ and Java. These languages got OO horribly, horribly wrong; so if you use them and dislike OO, it's possible that you dislike the language -- not OO. If you use CLOS, you'll see that functions are functions and data are data. CLOS just gives you some tools for calling different functions depending on the type of the data and for specializing subtypes. This is OO done right, and it is not what the author of this article is referring to. Objection 2 - Everything has to be an object. Everything has to have a type, yeah. But the line between "built-in type" and "object" should be blurry, and in CLOS it is. Again, if you are hating OO because of Java's implementation quirks... Objection 3 - In an OOPL data type definitions are spread out all over the place. I am not sure what the problem is here. Unless your code is all in one file, this is going to be a problem regardless of the programming "paradigm" you choose. When writing Lisp, I often put all my class and method definitions for one chunk of the app in the same file. I think this is what the author wants to do, and it is do-able and commonly done in CLOS. In Java, yeah, you have to put each class in its own file. That is irritating, but the problem is not OO. Objection 4 - Objects have private state. This is true. I prefer to write OO code that maps one object to another, rather than mutating an object's internals. The sad reality is that this approach is slower and uses more memory than the mutation approach, but I think it's easier to reason about and maintain. Computers are fast, anyway. So while it's possible to misuse OO, whatever that means for your particular tastes, it's also possible to not misuse it. If you hate OO, it is possible that you are doing it wrong.
- omouse 18y ago
  For Objection 1, Smalltalk also works since it's dynamically typed. There may be a bit more work to do to get it to do stuff in a CLOS-like way though. For Objection 2, well as you said, the distinction should be blurry. I really don't understand what his objection to Time being an object is. What Erlang is doing with deftype is basically creating a new "constructor" for an object that includes bounds-checking. The problem in Objection 3 is that he's dealing with file-based languages (and so are you). If you use any Smalltalk, you'll find a nifty browser that organizes things by package name, and there are even categories for methods. I wish people would stop posting ill-informed rants on Hacker News.
MHollender 18y ago
I'm interested in functional programming, but I think there are some features of OO that are a bit hard to reproduce in non-OO functional or to do anything similar. So you have a type. And you have functions that do something with instances of that type. Are there many functions that do something with it, such as set a certain boolean field in the type to true or false? If yes, you are in a world of hurt when you realize that every time something sets it to false you need to write it into a log, as you will have to change all functions. If you have just one function that sets that field - haven't you just reinvented a setter method? There are clumsy ways to do OO. But OO itself shouldn't just be judged from the clumsy ways. Python got it almost perfectly. You have a function, you have your local variables within the function, any time later on you can define functions within a function and then you have something very similar to a class, with the main function being the constructor of it. Or you can do the other way around, you define a class and later on if you need it you add a __call__() method and for all practical matters and purposes you have a function. WIN.
gruseom 18y ago
Several comments have objected to this as if it were stupid: In an OOPL data type definitions belong to objects. So I can't find all the data type definition[s] in one place. The point is that OO programs consist of many type declarations scattered everywhere. As complexity grows, it gets harder to understand what all the types are and how they are related. The textbook "shape" and "animal" examples never come close to revealing this problem: they're oversimplified and they refer to things already familiar from the world. In other words they rely on OO's roots in simulation, where it works ok. In any complex system, though, you have to go far beyond ready-at-hand concepts. You end up declaring all sorts of arbitrary types that exhibit the problem Armstrong is talking about. There isn't even an easy way to see what they all are. It gets harder and harder to change such programs because changing one type definition entails changing others. You can change how the internals of a class work (where it reduces to functions operating on private state), but significant overhaul of the class hierarchy itself is an order of magnitude harder than it should be (than it is in a program where you just have functions). Armstrong's reference to keeping everything in a single file is not because he believes everything should be kept in a single file. That should be obvious, since he's obviously not an idiot. His point is how much easier it is in certain non-OO languages to understand a program's type system. I think this is a valid criticism of OO because it cuts to the core of what people claimed was great about OO: that it helps to organize complex programs better and that it makes complex programs easier to change. Edit: Armstrong is obviously smart, and Erlang is a real contribution, but it is also true that he is not a very good writer. I find he's the kind of writer that I have to make an effort to understand, which in his case is worth it because his intuitions are worth paying attention to. Of course not everyone need feel that way. But some of the comments in this thread seem a little knee-jerk to me. Edit 2: Smalltalk is pretty clearly an exception to all of this. This has puzzled me for a long time. It just hit me maybe why: Smalltalk is actually not an OO language. Not in the sense we talk about OO nowadays. We've all been misled by the fact that it was the original OO language and that its creator introduced the term. Smalltalk's greatness comes from another place entirely, which is why no other OO language has equalled it.
- kilowatt 18y ago
  ...you really left us hanging there. Where does this supposed greatness-which-shall-not-be-named come from? The only distinguishing feature that I can recall about Smalltalk is that every operation is just passing a message--and that's certainly not unique among OO languages.
cool-RR 18y ago
If the author wants to explain to us why he thinks OO sucks, that is a legitimate criticism, even if for some of us it would be hard to swallow. However, the fact that the author does not acknowledge the advantages of OO, (even if he believes they are less significant that the disadvantages,) is a good enough reason to ignore his criticism.
bianco 18y ago
In my experience, OO is a good thing when you are able to imagine the 'objects' in some real-life representation (like GUI elements which are generally represented as 3 dimensional physical objects). Otherwise OO tends to be too abstract to help you, and already gets in your way. This is very simple to prove: give a group of experienced coders the same 2 problems to solve: one taken from a real world object, and the other purely theoretic; both to realize in OO. This experiment would show that the real world object problem is solved in a similar manner, and the theoretic one in all different ways... And yes, I use OO, but only with the libraries written in OO style, and never in my own code.
lgriffith 18y ago
Isn't this rather like saying than since a five pound sledge hammer can't fix watches, tools suck? I find it best to use the tool that is appropriate for the task. This is true even though you might be able to force fit a particular tool to a mismatched task. Saying that there is only one true way is always wrong. Especially since any of the ways we have are at best only good enough for some tasks, mediocre for many, and really horrible for others. The title should be translated to "Why One True Ways Suck" or on a really bad day "Everything Sucks".
richcollins 18y ago
Why don't erlang people understand that erlang processes are objects? - You can send them messages - Their state can be mutated through receipt of messages - They have private state - Their functions are associated with the data that they operate on
- gnaritas 18y ago
  Absolutely true, which makes Joe's rants against OO rather silly. He's been bitten by bad OO implementations and closed his mind to the idea of OO even though he created a version of it with Erlang.
ZamboniMan 18y ago
OO works becuase it roughly matches how we think. We see the world as objects at a basic level. As others mentioned, this makes coding more productive. It's a choice for the programmer, not the computer. If you need really fast code, use assembler. You have that choice. Code at the level required for the task.
- fauigerzigerk 18y ago
  OO doesn't match the way I think anyway. OO makes it appear as if all objects can do something, e.g. window.open(), list.add(item). In the real world some objects are passive, some objects are active and conscious and some complex objects have behaviour but don't respond to simple instructions (e.g the economy). I believe this is a very fundamental feature of how we think about the world and it's totally unlike OO. But I also think that it doesn't matter at all. Formal systems don't need to resemble language or the way we think about the world (or the way we think we think about the world) We don't naturally think like Snoopy swearing, but regular expressions are still a very productive tool for someone who has learned to think differently than he would naturally do. The same goes for maths and many other tools. I'm very skeptical about OO, but that's not because it doesn't match the way I think. I'm skeptical because OO APIs force me to know things I don't want to know. They constantly make me think about which class has a particular function. But the rationale for putting a function in one class or another is based on implementation considerations that are of no concern to me as a user of an API. It's mostly about which object's state is affected most, how dependencies are managed, what types of changes are expected, and so on. I've given this example elsewhere but here's the short version again: Say you want to initiate the sale of a property via some API. There are many objects involved: A buyer, a seller, a contract, an estate agent and a property. Which of the five classes involved contains the method you're looking for? It could be in any of these classes and I don't want to think about it. I want a sell(property, buyer, seller, contract, agent) function and the API should figure out its own state and dependency matters.
Allocator2008 18y ago
Christ, THANK YOU!!! Finally someone with the balls to say what needed to be said!! The object oriented emperor has no clothes. It creates problems and creates an industry to solve problems it created. Kind of like Christianity. It creates guilt so it can solve guilt by making people donate to the Church to relieve themselves of guilt the Church itself put on to them. Great scam, and so is OO. They will crucify you my friend, but you have spoken the TRUTH, and the history will adjudicate you accordingly!! Princeps autum justice, ille in parce est.
jganetsk 18y ago
For once, just once, I would like to see someone compare apples to apples: OO vs corresponding encapsulation techniques in functional languages (abstract data types, ML-style modules/functors, Haskell-style typeclasses). In case anyone was wondering, yes, the functional community loves namespacing, encapsulation, and creation of new data types with functions specifically intended for use on them. The real question is: How do we express relationships between data types... Do we use subtyping? (OO yes, functional no). How do we allow multiple types to see each others privates? (Friends/inheritance in OO, modules in Haskell and ML). How do we do polymorphism over static data/functions? (Basically, doesn't exist in OO... functors in ML and typeclasses in Haskell). The immutability debate is another discussion entirely.

85 points by ananthrk 18y ago

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. Obviously not if you use composition and if some objects are just your wrapper for your data structures.

swombat 18y ago

Summary: I don't understand programming much, I don't understand OO, I don't know how to do OO properly, and so I think OO sucks. This article is Not Even Wrong. It's not close enough to even being wrong to warrant a thought through response. The author needs to go and learn how to do OO properly before making wild declarations about "Why OO sucks". ================ Edit: worth clarifying this as I've just realised that this guy is supposed to be the author of a programming language (quite worrying if he is!) As I said, this is too far from even being wrong to be worth really debating point by point, so I'll just poke a few holes to demonstrate that I'm not just flaming: 1) functions and data structures belong in totally different worlds Anyone who's even glanced at SICP knows that the distinction between data and functions are vague at best. Certainly they are tightly coupled concepts. ------------ 2) 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. How does that have anything to do with the age of the captain? Not only the author's main point doesn't make sense, but he feels the latitude to make tangents about unrelated things that don't really have an impact on his obviously controversial main point. -------------- 3) The "time" example that he gives... In this example, he basically creates an ad-hoc object made of methods that return data. The only difference between this and proper OO is that this structure doesn't benefit from all the advantages of OO. But it's still a tightly coupled structure made of data (the values) and functions (the methods to access those values). -------------- 4) In an OOPL data type definitions belong to objects. So I can't 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. So now language design should be driven by whether you have a decent editor that allows you to manage more than 1 file? Seriously, the "Everything in 1 file" anti-pattern is not even worth arguing about... When someone makes such a dumb point, how can you take the rest of the article seriously? -------------- I could go on, but I think I'm proven my point. Either this article was not written by Joe Armstrong, or it casts severe doubt on the sanity of Erlang, or he's written it to troll the OO community.

jwilliams 18y ago
Agreed. Most of his reasons are straight tautologies - "Here is my definition of XYZ" - then, see how coincidentally that definition clashes with OO?
ananthrk 18y ago
The said author is Joe Armstrong (of Erlang fame)
- swombat 18y ago
  Yep, I just got that and updated my post to include argument supporting my point. Inventing a language doesn't preclude you from being sorely wrong.
  - ananthrk 18y ago
    Agreed. Not knowing the author is all the more better as the response will be not clouded by "OMG, he created Erlang :)"
    - jmtulloss 18y ago
      At the same time, Erlang handles its problem domain like a champ. Knowing that this was written by Joe Armstrong, you can see that he might be approaching this from a different angle than others, even if he is lacking in eloquence here. I would tend to agree that OO is pretty bad for highly parallel programs, which makes this all seem a bit more reasonable.
gaius 18y ago
Meanwhile Erlang is dominating C++ in its niche. Coincidence?
- swombat 18y ago
  I haven't heard of any games or embedded systems written in Erlang...

visitor4rmindia 18y ago

IMHO this is a pretty poor rant. Let me argue each point: * Data structure and functions should not be bound together In some cases encapsulation works really well. For example GUI elements. It is less true for "process-oriented" components. But the arguments he makes don't seem very well thought out. * Everything has to be an object I actually agree here. To my mind, the biggest problem with OOPS is that is slowly devours all other concepts until we are left trying to force-fit all problems into the OOPS mould. * In an OOPL data type definitions are spread out all over the place This just ignorance. * Objects have private state This is also a good point. Having state actually tends to being a "bad" thing to do. Of course, the entire purpose of the object is to capture some invariant, but an object doesn't make that clear. Many objects contain instance variables that should actually be parameters. * Why is OOPS popular? Because it makes it easier and safer to get programmers working together as a group. The vocabulary of available objects is a simple and somewhat elegant way of communicating. (EDIT: Corrected layout.)

jwilliams 18y ago
He probably has a point in some ways, but some of the points seem so bad they are almost impossible to rebuff - e.g. functions are functions, data is data, therefore they must be separate? Additionally, he's run up against the pitfall with OO - it actually lacks a definition. It's got lots of dimensions and facets, and each implementation interprets these in it's own way... e.g You could argue that SmallTalk's message passing metaphor was the precursor to Erlang's model.
- visitor4rmindia 18y ago
  Actually the first line sums up the problem with this article: >When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". It's more a personal rant than a well thought-out article.
  - access_denied 18y ago
    What is wrong with a personal rant? Does every writing needs to be a well thought-out article? Discussions. Essay. Opinions. Why not?

mariorz 18y ago

"Data structures just are. They don't do anything. They are intrinsically declarative. 'Understanding' a data structure is a lot easier than 'understanding' a function. " I'm possibly damaged from a few years of OOP but how do you separate a data structure from its functions? e.g. How can a B-tree mean anything separate from its search/insert/delete operations?

visitor4rmindia 18y ago
In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself. For instance most examples on the net just assume keys to be long numbers but that is obviously insufficient for an actual application. Keys could be 20-bit hashes, strings, floats, doubles etc. The same applies to a lesser degree to the offsets (at leaf node level) and any embedded values. Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects.
- mariorz 18y ago
  In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself. I'm confused, you store values in the tree but in itself it is not a data structure? Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects. I see a B-tree as a data structure not an object per se, I still don't see how it would mean anything without its operations.
  - visitor4rmindia 18y ago
    Let me try and give an example. Let's assume we are modelling a non-leaf node which contains long keys and long offsets. We can do it in any of the following ways: |offset0|key1|offset1|key2|offset2|key3|offset3......| OR |key1|key2|key3...|offset0|offset1|offset2|offset3...| OR |offset0|offset1|offset2|offset3...|key1|key2|key3...| OR |count|key3|key1|key7...|offset0|offset1|offset2.....| <== Binary search-able keys In all of these cases, the data structure is different but the basic B-Tree algorithm remains the same. You can implement the algorithm once (using templates (C++), macros (C), or a weakly typed language (Lisp/Scheme)) and re-use it with any and all data structures that come up later. EDIT: Forgot offset0

gojomo 18y ago

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.)

silentbicycle 18y ago
(He's the main designer of Erlang, FWIW.)
- gojomo 18y ago
  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.)
  - silentbicycle 18y ago
    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.)

sunkencity 18y ago

If people get angry while reading this article, there must be some truth in what he says. Dissing OO is still swearing in the church. I programmed for a long time not knowing OO and it was fine, there are other ways of encapsulation/isolation of code that works just as well. I don't really see that there's a big difference, and there's a certain element of religion about OO vs Functional. Both have their own merits in different types of applications. Still it's nice with someone who stands up for the functional approach.

barrkel 18y ago
No anger here; just unmoved.
jff 18y ago
OO and Functional are not the only two styles of programming out there. There's actually Functional and Imperative (and maybe others?), with OO being an additional concept that gets tacked onto both functional and imperative languages.
- ricky_clarkson 18y ago
  OO exists on top of the imperative paradigm, never the functional one. If you disagree, please define OO.
  - parenthesis 18y ago
    Common Lisp is a multi-paradigm language, but its OO features can be used in a functional style.
  - hassy 18y ago
    1. OO has no precise and universally accepted definition. http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html 2. Parameterized modules in Erlang can be seen as a form of lightweight functional OOP. http://www.lshift.net/blog/2008/05/18/late-binding-with-erlang http://www.lshift.net/blog/2008/05/18/late-binding-with-erla... http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf

jonke 18y ago

If the people who got upset of the article should unite of what OO is we could read that one comment. In the meantime read http://www.paulgraham.com/reesoo.html http://www.paulgraham.com/reesoo.html Be neutral. Think. Could Joe have some valid arguments ? As someone said, patch your brain into Net Neutral.

niv 18y ago

then what about abstract data types?

time_management 18y ago

OO concepts are occasionally cool and useful. Note the use of the word occasionally. 90+% of the time, when you create an object, what you really want is a struct/record. Most methods should really be static. Most of the power that does come from OO comes from its ability to foster a hierarchical type system in an extensible way. OO smells like something that was invented to give "business" types the illusion that they can understand code without reading it in detail. "This is 'like a' Chair."

narag 18y ago
90+% of the time, when you create an object, what you really want is a struct/record. I don't. I've been fortunate enough to use a language that doesn't force the "everything's an object" mantra. The two real advantages of OOP (from my POV anyway) are encapsulation (minimal interface) and convenient syntax: the first parameter turns to be a prefix so it resembles human language, a question of usability really.
- silentbicycle 18y ago
  Encapsulation can also be handled well at the module/package system level, though. (The package system in OCaml has some particularly interesting features.) The latter is a mixed blessing. It's often very convenient, but sometimes there isn't a clear answer which object should be the primary one in a binary operation. (This is particularly troublesome with non-commutative operations.) Lua's syntactic sugar for this ( obj:method(args) vs method(obj, args) ) seems like a good balance; it's explicit that it's just sugar for convenience, but you aren't required to use it.
  - narag 18y ago
    Encapsulation can also be handled well at the module/package system level, though Yes, it's more or less the same, but you can define public and private parts for individual objects. The good part of encapsulation is separating interface from implementation: you can publish a data type without giving access to its innards. sometimes there isn't a clear answer which object should be the primary one in a binary operation I really haven't found it to be a problem in practice.

jcromartie 18y ago

I have to say that I agree with this only as long as we're talking about languages that don't have excellent OO capabilities. C++, Java, C#, and most others failed to impress me with their approach to OOP. But then I got to work in Smalltalk, and it dawned on me: "this is what OOP is supposed to be like."

access_denied 18y ago
Would you say Objective-C has it "right"? In other words, should a beginner to OOP (me) learn Smalltalk or Objective-C (first)?
- jimbokun 18y ago
  If you want to learn maybe the "purest" implementation of object oriented programming, learn SmallTalk. Everything in SmallTalk is an object, and objects communicate exclusively by sending each other messages. Almost every other programming language has some non-OO "escape hatch," like direct access to data fields or primitive (non-object) data types. Use Objective-C if you want to program the Mac or iPhone in the near future. It largely copies the SmallTalk model, but grafts it on to C, which means that you can still do all the non-OO things that C can do. This engineering compromise seems to have turned out to be a pretty good design choice, but perhaps not as aesthetically pleasing as the "pure" SmallTalk design.
  - jmtulloss 18y ago
    I would also add that Smalltalk might be more frustrating to do "cool things". It's a gratifying language to learn as an experienced developer, but for somebody just starting out, the fascination comes from the end result, not the elegance of getting there. I know when I was first starting out, I wasn't capable of writing an elegant line of code. I barely am now, but at least I can recognize it when I see it.

trezor 18y ago

Knowing how many fuckups and bugs which have happened trough the years because of incorrect handling of times and dates, I can't believe he advocates that they should be "ubiquitous ... data structures representing times (which) can be manipulated by any function in the system." Obviously the thought of a one single encapsulated DateTime class which manipulates time and dates (correctly) for us is a horrible idea.

iamwil 18y ago

As a disclosure, I've been using Ruby for the past three years, and it's about as object-y as you can get. However, Ruby opened my eyes a bit to exploring other languages. Point is, as I started looking at other languages in depth, I found myself using objects a little bit less, especially in the design pattern sense. Some problems in the traditional 23 design patterns just disappear in dynanmic languages. After programming in Lua and Javascript, I find objects nice, but optional. Nowadays, I sort of just use classes to scope and namespace. I keep state in classes when it makes sense. To counter the point about state, Erlang programs do have state. They're just contained locally within a function. Since Erlang has tail recursion, you just call the same function recursively and pass the state variable you want to keep at the very end of the function for the lifetime of the program. Because it's tail recursion, there's no stack overflow. Also, Erlang threads can keep 'state' inside of the Mnesia database that comes with Erlang. State is only evil when it's shared. Because state is contained locally in a function, a single Erlang thread can do whatever it wants, whenever it wants with those variables. Threads communicate through message passing. Therefore, no need for locks, mutexes or semaphores. Along with the low overhead of thread creation (~300 bytes) they're part of the reason why Erlang has great concurrency properties.

TweedHeads 18y ago

Humans walk(), eat() and rest(). Invoices don't do shit. We need both.

visitor4rmindia 18y ago
If I understand you correctly you're saying something like TweedHeads.walk(), TweedHeads.eat() and TweedHeads.rest() make it sensible to define Human as a class. But then how would you attach makelove() or fight() or discuss() to a single Human? When do we use TweedHeads.discuss(visitor4rmindia) vs visitor4rmindia.discuss(TweedHeads)?
- ivey 18y ago
  It took me a minute to realize that TweedHeads was an object and not a class.
  - MHollender 18y ago
    I figure humans are best modelled as singletons, each being one instance of his own class... (This is why prototype-based OO would sometimes be more useful)
- MHollender 18y ago
  (Python) TweedHeads.Say("something", visitor4rmindia.Listen) visitor4rmindia.Say("something else",TweedHeads.Listen) The Say method takes 2 parameters, what is said in a string, and a reference to the listening method of the partner. The Say method will first write into the it's private log "I'll remember for a while, I said to {listenmethod.im_self}: something" and do perhaps do some other stuff, and then call the referred Listen method passing in the "something" as a parameter and also passing self as a parameter, to let him know who said it to him. The Listen method of that object will write into it's own private log "I'll remember for a while: this guy {the passed-in self} told me something", and then perhaps do some other stuff. Of course this is functional/OO, and a pretty awesome kind of OO, it being Python, not just basic mainstream OO.
- kilowatt 18y ago

pj 18y ago

I won't go so far as to say OO sucks, but I have noticed in my own code, that I have tended to use OO concepts a little bit and functional concepts a lot. Over time, I'm using less and less OO and more and more functional, so... that tells me OO wasn't all it was cracked up to be. The biggest problem I see with OO is that it doesn't map well to relational models and OO databases aren't that popular.

charlesju 18y ago

I think Alan Kay just cried a little inside.

c00p3r 18y ago

Programmers are talking about ideas, while coders are talking about tools. =) I'm personally prefer the description of mr. Booch - OOA/OOD/OOP is the way to manage the complexity of a problem. Unfortunately the rest of his book is an advertisement of the RUP and UML - yet another tools.

jonsen 18y ago

Von Neuman architecture sucks. From our educated and elevated point of view I think we can all agree on that. At least if we transcribe to "programming in machine language sucks". Perhaps one day we may elevate to agreement on "OO architecture sucks". OO is a successful technology measured by what has been accomplished with it. The von Neuman architecture is even more successful. The one and only architecture behind all general purpose computers. But no sane programmer would touch machine code directly. I have always thought that OO was wrong, in some sense at least. But I have to touch it. There is no higher and better level. There are alternatives but on the same level. So they suck in their own ways. I remember when I started forming my mental pictures of what programming in the large was all about. How to think about it. How to structure it in my mind. I read Object-Oriented Modeling and Design by Rumbaugh et.al. Even if the authors didn't succeed in explaining it fully, I got the vivid impression, that they wanted me to believe, that a computer model should be structured along three dimensions: data, functionality and events. A space with a recording axis, data, an activity axis, functions, and a time axis, events. Though a somewhat fuzzy picture, I "saw" these three dimensions as orthogonal and of equal importance in structuring and building the complex structures called programs. I find OO to intermingle the data-function-plane but leaving timing in the cold. A skewed space. I'm looking forward to the tools and technology, that will support my clean and "right" design model in a non-skewed concrete "code" space. Well, if they ever arrive, I might then have an even better mental model and find my self stuck with the new and better but sucking tools.

jmtulloss 18y ago
I'm sorry, this is way too thick of a block for me to read through. If you want a serious discussion of your idea, you might want to lay out your argument more carefully.

schtog 18y ago

I always thought that OO encourages not rigorous abstract thinking but fuzzy everyday thinking with arbitrary definitions.

msluyter 18y ago

I'm seeing a trend here: 1. X used to be regarded highly but turns out to be imperfect or suboptimal for certain problem domains. 2. Write "why X sucks" blog post. 3. Profit!

atlei 18y ago

Erlang is a functional language specially designed (and suitable) for concurrent programming. His rant is partially correct (at best), especially looking at OOP from a functional programming point of view. However, developers in the real world who doesn't focus on concurrent programming have different needs. I'll comment his objections from a C++ perspective (which is a multi-paradigm language, not purely OO): Objection 1 - Data structure and functions should not be bound together - you are free to store all your data structures in a single file, and access them from anywhere. However, using classes will let you hide some of the data structures which are not necessary globally, reducing the cognitive load. Objection 2 - Everything has to be an object - Not in C++. You use classes where appropriate, and ordinary functions elsewhere. I agree that everything shouldn't be an object. Objection 3 - In an OOPL data type definitions are spread out all over the place. - similar to objection 1. You CAN store all definitions in a single include file, but for large projects this can be a LOT of data definitions, where many/most of them are only relevant for parts of the applications. Hiding data definitions in separate classes will make it easier to focus on the RELEVANT data depending on which class/function you use. Objection 4 - Objects have private state. - again, similar to 1 and 3. "State is the root of all evil". If you store all data in a single file, then you have one giant global mess. By assigning them to a class, you clearly state the responsibility and scope of the variables. A private state is nobody's business but the class. You don't HAVE to have private state for objects,but then you either need to pass all data to each function, or use global variables instead. For Erlang (functional programming) these objections make (some) sense since you DON'T want any state whatsoever to facilitate concurrency. However, saying that OO sucks is stupid, and the four reasons for why OO was popular is not even worth responding to. I don't think functional programming will become more popular due to this rant....

jrockway 18y ago

Objection 1 - Data structure and functions should not be bound together This is not true of "OO", it's just true of OO in languages like C++ and Java. These languages got OO horribly, horribly wrong; so if you use them and dislike OO, it's possible that you dislike the language -- not OO. If you use CLOS, you'll see that functions are functions and data are data. CLOS just gives you some tools for calling different functions depending on the type of the data and for specializing subtypes. This is OO done right, and it is not what the author of this article is referring to. Objection 2 - Everything has to be an object. Everything has to have a type, yeah. But the line between "built-in type" and "object" should be blurry, and in CLOS it is. Again, if you are hating OO because of Java's implementation quirks... Objection 3 - In an OOPL data type definitions are spread out all over the place. I am not sure what the problem is here. Unless your code is all in one file, this is going to be a problem regardless of the programming "paradigm" you choose. When writing Lisp, I often put all my class and method definitions for one chunk of the app in the same file. I think this is what the author wants to do, and it is do-able and commonly done in CLOS. In Java, yeah, you have to put each class in its own file. That is irritating, but the problem is not OO. Objection 4 - Objects have private state. This is true. I prefer to write OO code that maps one object to another, rather than mutating an object's internals. The sad reality is that this approach is slower and uses more memory than the mutation approach, but I think it's easier to reason about and maintain. Computers are fast, anyway. So while it's possible to misuse OO, whatever that means for your particular tastes, it's also possible to not misuse it. If you hate OO, it is possible that you are doing it wrong.

omouse 18y ago
For Objection 1, Smalltalk also works since it's dynamically typed. There may be a bit more work to do to get it to do stuff in a CLOS-like way though. For Objection 2, well as you said, the distinction should be blurry. I really don't understand what his objection to Time being an object is. What Erlang is doing with deftype is basically creating a new "constructor" for an object that includes bounds-checking. The problem in Objection 3 is that he's dealing with file-based languages (and so are you). If you use any Smalltalk, you'll find a nifty browser that organizes things by package name, and there are even categories for methods. I wish people would stop posting ill-informed rants on Hacker News.

MHollender 18y ago

I'm interested in functional programming, but I think there are some features of OO that are a bit hard to reproduce in non-OO functional or to do anything similar. So you have a type. And you have functions that do something with instances of that type. Are there many functions that do something with it, such as set a certain boolean field in the type to true or false? If yes, you are in a world of hurt when you realize that every time something sets it to false you need to write it into a log, as you will have to change all functions. If you have just one function that sets that field - haven't you just reinvented a setter method? There are clumsy ways to do OO. But OO itself shouldn't just be judged from the clumsy ways. Python got it almost perfectly. You have a function, you have your local variables within the function, any time later on you can define functions within a function and then you have something very similar to a class, with the main function being the constructor of it. Or you can do the other way around, you define a class and later on if you need it you add a __call__() method and for all practical matters and purposes you have a function. WIN.

gruseom 18y ago

Several comments have objected to this as if it were stupid: In an OOPL data type definitions belong to objects. So I can't find all the data type definition[s] in one place. The point is that OO programs consist of many type declarations scattered everywhere. As complexity grows, it gets harder to understand what all the types are and how they are related. The textbook "shape" and "animal" examples never come close to revealing this problem: they're oversimplified and they refer to things already familiar from the world. In other words they rely on OO's roots in simulation, where it works ok. In any complex system, though, you have to go far beyond ready-at-hand concepts. You end up declaring all sorts of arbitrary types that exhibit the problem Armstrong is talking about. There isn't even an easy way to see what they all are. It gets harder and harder to change such programs because changing one type definition entails changing others. You can change how the internals of a class work (where it reduces to functions operating on private state), but significant overhaul of the class hierarchy itself is an order of magnitude harder than it should be (than it is in a program where you just have functions). Armstrong's reference to keeping everything in a single file is not because he believes everything should be kept in a single file. That should be obvious, since he's obviously not an idiot. His point is how much easier it is in certain non-OO languages to understand a program's type system. I think this is a valid criticism of OO because it cuts to the core of what people claimed was great about OO: that it helps to organize complex programs better and that it makes complex programs easier to change. Edit: Armstrong is obviously smart, and Erlang is a real contribution, but it is also true that he is not a very good writer. I find he's the kind of writer that I have to make an effort to understand, which in his case is worth it because his intuitions are worth paying attention to. Of course not everyone need feel that way. But some of the comments in this thread seem a little knee-jerk to me. Edit 2: Smalltalk is pretty clearly an exception to all of this. This has puzzled me for a long time. It just hit me maybe why: Smalltalk is actually not an OO language. Not in the sense we talk about OO nowadays. We've all been misled by the fact that it was the original OO language and that its creator introduced the term. Smalltalk's greatness comes from another place entirely, which is why no other OO language has equalled it.

kilowatt 18y ago
...you really left us hanging there. Where does this supposed greatness-which-shall-not-be-named come from? The only distinguishing feature that I can recall about Smalltalk is that every operation is just passing a message--and that's certainly not unique among OO languages.

cool-RR 18y ago

If the author wants to explain to us why he thinks OO sucks, that is a legitimate criticism, even if for some of us it would be hard to swallow. However, the fact that the author does not acknowledge the advantages of OO, (even if he believes they are less significant that the disadvantages,) is a good enough reason to ignore his criticism.

bianco 18y ago

In my experience, OO is a good thing when you are able to imagine the 'objects' in some real-life representation (like GUI elements which are generally represented as 3 dimensional physical objects). Otherwise OO tends to be too abstract to help you, and already gets in your way. This is very simple to prove: give a group of experienced coders the same 2 problems to solve: one taken from a real world object, and the other purely theoretic; both to realize in OO. This experiment would show that the real world object problem is solved in a similar manner, and the theoretic one in all different ways... And yes, I use OO, but only with the libraries written in OO style, and never in my own code.

lgriffith 18y ago

Isn't this rather like saying than since a five pound sledge hammer can't fix watches, tools suck? I find it best to use the tool that is appropriate for the task. This is true even though you might be able to force fit a particular tool to a mismatched task. Saying that there is only one true way is always wrong. Especially since any of the ways we have are at best only good enough for some tasks, mediocre for many, and really horrible for others. The title should be translated to "Why One True Ways Suck" or on a really bad day "Everything Sucks".

richcollins 18y ago

Why don't erlang people understand that erlang processes are objects? - You can send them messages - Their state can be mutated through receipt of messages - They have private state - Their functions are associated with the data that they operate on

gnaritas 18y ago
Absolutely true, which makes Joe's rants against OO rather silly. He's been bitten by bad OO implementations and closed his mind to the idea of OO even though he created a version of it with Erlang.

ZamboniMan 18y ago

OO works becuase it roughly matches how we think. We see the world as objects at a basic level. As others mentioned, this makes coding more productive. It's a choice for the programmer, not the computer. If you need really fast code, use assembler. You have that choice. Code at the level required for the task.

fauigerzigerk 18y ago
OO doesn't match the way I think anyway. OO makes it appear as if all objects can do something, e.g. window.open(), list.add(item). In the real world some objects are passive, some objects are active and conscious and some complex objects have behaviour but don't respond to simple instructions (e.g the economy). I believe this is a very fundamental feature of how we think about the world and it's totally unlike OO. But I also think that it doesn't matter at all. Formal systems don't need to resemble language or the way we think about the world (or the way we think we think about the world) We don't naturally think like Snoopy swearing, but regular expressions are still a very productive tool for someone who has learned to think differently than he would naturally do. The same goes for maths and many other tools. I'm very skeptical about OO, but that's not because it doesn't match the way I think. I'm skeptical because OO APIs force me to know things I don't want to know. They constantly make me think about which class has a particular function. But the rationale for putting a function in one class or another is based on implementation considerations that are of no concern to me as a user of an API. It's mostly about which object's state is affected most, how dependencies are managed, what types of changes are expected, and so on. I've given this example elsewhere but here's the short version again: Say you want to initiate the sale of a property via some API. There are many objects involved: A buyer, a seller, a contract, an estate agent and a property. Which of the five classes involved contains the method you're looking for? It could be in any of these classes and I don't want to think about it. I want a sell(property, buyer, seller, contract, agent) function and the API should figure out its own state and dependency matters.

Allocator2008 18y ago

Christ, THANK YOU!!! Finally someone with the balls to say what needed to be said!! The object oriented emperor has no clothes. It creates problems and creates an industry to solve problems it created. Kind of like Christianity. It creates guilt so it can solve guilt by making people donate to the Church to relieve themselves of guilt the Church itself put on to them. Great scam, and so is OO. They will crucify you my friend, but you have spoken the TRUTH, and the history will adjudicate you accordingly!! Princeps autum justice, ille in parce est.

jganetsk 18y ago

For once, just once, I would like to see someone compare apples to apples: OO vs corresponding encapsulation techniques in functional languages (abstract data types, ML-style modules/functors, Haskell-style typeclasses). In case anyone was wondering, yes, the functional community loves namespacing, encapsulation, and creation of new data types with functions specifically intended for use on them. The real question is: How do we express relationships between data types... Do we use subtyping? (OO yes, functional no). How do we allow multiple types to see each others privates? (Friends/inheritance in OO, modules in Haskell and ML). How do we do polymorphism over static data/functions? (Basically, doesn't exist in OO... functors in ML and typeclasses in Haskell). The immutability debate is another discussion entirely.