Things to hate about OOP

http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/

by knieveltech • 16 years ago

84 73 16 years ago

blog.jot.fm

loup-vaillant3• 16 years ago

> OOP is about taming complexity through modeling […]

But, what kind of programming isn't?

thesz3• 16 years ago

The question is: how effective?

jrockway2• 16 years ago

Pretty effective.

Yes, 99.99% of Java programmers do it wrong. That's because they are not programming, they are typing stuff into a computer to make sure next week's paycheck shows up on time.

Or, they think "programming is fun", and want to solve a problem. So they solve the problem in a way they know how, publish their solution to teh intarwebs, and are done. This results in a solution to a problem, not easy-to-maintain code.

Writing good code requires practice, discipline, skill, taste, continuous re-evaluation of the design, extensive thinking, and extensive learning. Not many people care enough to do it right. The program works today, and if something needs to be changed tomorrow, well, they'll change it tomorrow.

The problem is not OO, the problem is that good software is never demanded (because people think it's impossible).

loup-vaillant3• 16 years ago

No it isn't. Not yet. You have to define "OO" first. You have to point to a cluster in program-space worth defining, call that "OO", and call the rest "not OO". There could be fuzzy limits, but some programs have to be clearly OO, and some has to clearly not be.

I tried, and I hit two little snags:

(1) There is no agreed upon "OO" cluster. Ask Alan Kay and Bjarne Stroustrup. Most programmers even make a purely (and meaningless) syntactical distinction, calling `foo.bar(x)` OO, while calling `bar(foo, x)` not OO; or calling C++ classes OO, and calling C structs + functions not OO, even when they don't use inheritance in C++.

(2) Actually, "OO" is now meaningless. It doesn't have an interesting predictive power. No cluster in program space worth categorizing can reasonably be called "OO", because other existing terms will always be preferable. So we should stop using that term.

bad_user2• 16 years ago

     Classes exist only in our minds. Can you give me a single real-world 
     example of class that is a true, physical entity?

Sure I can ... before building a car, you need to have a blueprint first.

I know that OOP is no panacea and that it has problems and so on. But personally I haven't learned anything from reading this article.

metageek5• 16 years ago

>before building a car, you need to have a blueprint first.

But the blueprint is not the class; it is a copy of the instructions on how to instantiate the class.

igrekel3• 16 years ago

In the case of a car, not really, the assembly is entirely different matter dealt with by a different team. The car's blueprint may have to change to accommodate assembly issues but the car's blueprint is really describing the car not the assembly process.

russellallen2• 16 years ago

This is a roast, so picking it apart is to spoil the fun a bit :)

But: "If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”. Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly “Everything is an object” cannot be the essence of the paradigm."

Even in Smalltalk, packages, numbers and classes are all objects. Primitives are methods, which are objects.

In Self, variables (in Selfspeak 'slots') are also objects.

jcromartie• 16 years ago

Yeah, I thought maybe he was confusing ST with Java. In Java are those things not objects.

igrekel3• 16 years ago

People always focus on the everything is an object bit, I remember reading Alan Kay saying that the idea of messaging between parts of the software was much more central than inheritance or even the notion of objects.

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

But I agree that the fact that so much is an object makes Smalltalk so much more flexible. I have not done any real work in Self, so I won't comment.

andolanra• 16 years ago

He mentions that in Smalltalk, everything is an object, "Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on." This statement isn't quite correct; for example, both classes and numbers are objects in Smalltalk, as are all the primitive types such as booleans. In fact, Smalltalk's if-then statement is achieved by sending boolean objects the ifTrue:ifFalse: message with code blocks as arguments, e.g.

    (5 < 6) ifTrue: ['yes'] ifFalse: ['no']

which returns the string 'yes' if the 5 object returns true after being sent the < message with 6 as an argument.

The problem—as Paul Graham pointed out—is one of terminology. "Object oriented" means different things to different people, and what would be appropriate for an all-you-can-do-is-send-a-message system like Smalltalk is not going to be appropriate in a weakly statically typed, early-binding system like Java, which makes reasoning about all of OOP at the same time a difficult proposition.

wladimir3• 16 years ago

Is it just me or does this sound like an old, bitter man raging and remeniscing old times, when things were simple and procedural?

I'm not saying OOP is perfect. It's not. But to say procedural programs are easier to understand than OOP ones I have to simply disagree (based on the real world cases I have seen).

fleitz• 16 years ago

Most OO programs ARE procedural. (eg. Anything written in Java/C#/C++)

OO does not eliminate procedural code, it merely encapsulates it.

arethuza• 16 years ago

As with all discussions of this type it abounds with false dichotomies - as you say all OO programs contain an element of procedural code and it is pretty difficult to avoid objects and classes completely if you use a language where they are the primary means of data and procedural abstraction.

wladimir3• 16 years ago

Yes I meant "procedural-only, pre-OO".

A lot of C software (one example: glib, as used by GNOME) these days is also OO, without any language support. OO is about encapsulation, seperation of concerns, and so on, generally resulting in more readble code.

Of course it can be overdone. I've also seen software more like OO-extremism, in that it was almost impossible to see what called what, or how the loosely-knit bunch of objects, interfaces, abstractions managed to do anything at all. Eclipse has a few projects guilty of this.

eddieplan9• 16 years ago

The one thing I hate about OOP is that it is so ubiquitous that many manager-types think everything must be done in OOP.

lawn• 16 years ago

You know you've hit a quality post when he's arguing with Chuck Norris jokes.

redthrowaway2• 16 years ago

Chuck Norris argues with Stallman jokes.

redthrowaway2• 16 years ago

I hate when I get trolled by drunk me.

vrotaru• 16 years ago

If there is anything I hate OO is for the triumphalism of its proponents. Anyway, that's what I've come to think of main programming styles:

Imperative style - programming with a global context.

OO style - programming with a local, implicit context

Functional - programming with no context. Or explicit context.

And yes, Virginia, complex problems will stay complex no matter which style you use.

zby• 16 years ago

This is spot on! I would only change that from 'context' to 'state', because it is the state that matters.

gnaritas• 16 years ago

I love this description, it gets right to the core of the issue. Well done sir!

supersillyus2• 16 years ago

I think those are reasonable descriptions, but they're not quite how I see them. I think OO is orthogonal to imperative vs functional. You can program OO in a pure functional language, and you can do pretty typical C programming with OO.

shin_lao• 16 years ago

For a more clever criticism of OOP:

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

-Alexander Stepanov

edit : interview here http://www.stlport.org/resources/StepanovUSA.html

mtodd• 16 years ago

Great observation about starting with proofs.

This is especially true when you step outside of the code and look at the problems being solved: if you don't already have a proof of concept, and even before that, if you don't have a sound problem to solve, you will not be able to produce intelligible proofs and axioms will be difficult if not impossible.

Mechanically, I'll prove to myself something works the way I want or need to in a REPL and then implement the axiom from that... which is sorta in the right direction :)

davidmathers• 16 years ago

I think this is pretty well stated:

There is no value in code being some kind of model or map of an imaginary world. I don't know why this one is so compelling for some programmers, but it is extremely popular. If there's a rocket in the game, rest assured that there is a "Rocket" class (Assuming the code is C++) which contains data for exactly one rocket and does rockety stuff. With no regard at all for what data tranformation is really being done, or for the layout of the data. Or for that matter, without the basic understanding that where there's one thing, there's probably more than one.

Though there are a lot of performance penalties for this kind of design, the most significant one is that it doesn't scale. At all. One hundred rockets costs one hundred times as much as one rocket. And it's extremely likely it costs even more than that! Even to a non-programmer, that shouldn't make any sense. Economy of scale. If you have more of something, it should get cheaper, not more expensive. And the way to do that is to design the data properly and group things by similar transformations.

It's from this blog post called "3 Big Lies": http://cellperformance.beyond3d.com/articles/2008/03/three-b...

When I read it I thought: "That's a pretty common understanding isn't it? Not really a big lie." Then a few days ago I saw this: http://www.quora.com/What-is-the-best-mental-model-for-objec...

Facepalm. Note the "M.S. degree in computer science." WTF? To me that describes exactly how not to think about OOP.

I have Stepanov's book. It's only 240 pages, but 50% math. I haven't been able to get through it yet.

eru3• 16 years ago

I agree, especially about the mathematics.

Only starting with algorithms bugs me. A focus on data structures seems much more natural. (On the other hand, data structures are intimately tied to algorithms. What would a red-black tree be without insert, delete, look-up?)

supersillyus2• 16 years ago

I've seen that quote in a number of threads criticizing OO, and I don't think I fully understand it. Could someone explain what the practical edge of his argument is here? Or is it just a theoreticians complaint, taking a (perhaps simplistic) definition of OO and declaring it unsuitable? Everyone agrees in theory that proofs and generic code are great, but in practice it seems that most programs (at least, the ones that I've seen) aren't conglomerations of mathematically reasonable abstractions, but fairly monomorphic domain-specific actions that would benefit more from what OO offers than from proofs and generic regular types.

russellallen2• 16 years ago

Btw, for context, here is his publications list: http://scg.unibe.ch/staff/oscar/onpubs

He's not an anti-OOP guy, he's a pro-OOP guy who's giving a roast as the banquet speech at ECOOP.

Synaesthesia• 16 years ago

Object oriented programming has vastly simplified and improved programming. Come on! I would hate to develop an average GUI app without OO!

microtonal• 16 years ago

Yes, but UI is a typical use case where OOP works well. Everything can neatly be distinguished in classes: buttons, combo boxes, etc.

But look at numerical software implemented as OOP. Quite often it is absolutely horrible. I wrote such dreadful and unmaintainable code as well, because it was taught in school that OOP everywhere is the way to go.

OOP and inheritance is often mistaken as the path to genericity. Parametric polymorphism with constraints (e.g. typeclasses) is far more useful to that end.

OOP is great in some domains, but the 'OOP everywhere' philosophy needs to go. We have already tainted enough generations of students with such beliefs.

tkahn6• 16 years ago

> Just because your Java program compiles does not mean it has no errors (even type errors).

This is because

a) Java allows arbitrary subtype casting of object reference types

    Object s = "string"; 
    Integer foo(Integer i) {
       return i.intValue() + 2;
    }
    foo((Integer) s); //runtime error

b) null is valid value for all object reference variables.

    foo(null); //runtime error

Java should not be used to point out the faults of static typing.

lispm• 16 years ago

foo := 2 * a + b;

No type checking will ever get that this is simply the wrong formula, computes as (2 * a) + b and was supposed to be 2 * (a + b) .

Dn_Ab2• 16 years ago

Just like no car will ever be able to transfer hundreds of people across an ocean.

That is not the purpose of static types, instead they offer a basic guarantee on correctness, a minimal correctness proof on the structures of the program and in particular a sanity check on your logic to see if the structures implied by your types are in fact inhabited (excluding bottom type).

Or say if the type diagrams on a series of function you are trying to use commute.

See http://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspond... for some interesting stuff.

thesz3• 16 years ago

First, this is taken outside of context. Second, you're trying to disprove wrong thesis.

Let's take this again into context first.

In the proper context our wrong formulae will be brought up by running functional tests by field expert (or even earlier, by programmer itself). Functional tests, as opposed to unit tests, checks validity of the program as a whole in relation to problem it should solve. So they are much fewer and quite often all external.

So this is actually no-problem.

Let me reconstruct that implicit thesis you're trying to disprove.

As I can suggest from my experience and your nickname, you're trying to disprove thesis that "types solve all problems".

But real people use types not to solve all their programming-related problems, but to solve as many of them as they see fit for the task at hand.

All software processes revolve around simple thesis: the cost of defect elimination is proportional to the time between defect introduction and defect discovery. PSP/TSP, ALL Agile processes, etc.

Type systems greatly reduce that time. As do REPL and unit-tests. But, compared to unit tests, they require much less effort from programmer.

So, yes, we all need testing. Type systems, though, reduce areal of tests to where they naturally belong.

PS In my opinion, programmer should seek strongly typed language with REPL.

Seth_Kriticos• 16 years ago

That's a pretty negative article. Would be much more useful if he'd put suggestions on how to make it better in each point, maybe with some proof of concept.

As for the topic at hand. OOP is certainly no silver bullet, and not suited for everything (an example would be an OS kernel, see the attempt of Linux).

Generally though I don't enjoy the freedom to do systems programming all the time, and static procedural compiled languages are not a solution to everything.

At times when I want to bring something nice to the screen, I actually need a framework, a set of libraries that make me not have to invent the wheel again. Best stuff I saw in this category is written in C++/OOP.

Other times I just want to do some data processing, and a scripting language like bash or python does wonders in time efficiency for quick and dirty stuff, and OOP is only of minor importance for these things.

To add to the spirit of the article, and be a bit negative: The main problem with OOP I know of is, that it's harder to get an overview of a larger software project, as you have to familiarize yourself with a huge object dependency tree instead of the core data model and flow.

wladimir3• 16 years ago

Linux attempted to make an object-oriented kernel and failed? Can you give a link?

Small correction, btw: in Python everything is an object and you have classes n' stuff, making it just as 'OOP' as C++, Java.

dfox• 16 years ago

Making it several orders of magnitude more 'OOP' than C++ and Java.

cdavid• 16 years ago

Python is clearly described as an OOP programming language, yet, interestingly, it does not have key features often atteched to OOP: it has no enforced encapsulation, and inheritance plays a very minor role in designing python programs.

As Alan Kay described it, OOP should be about very late binding, messaging and state hiding/protection (http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...). That's completely different from most what people describe as OOP (by that definition, a statically typed language cannot be OOP). The notion of multiple algebra associated to objects mentioned by Stepanov was already considered before, so I don't buy that argument much. Also, as much as I admire in some perverse sense what the STL can do with C++, I don't think it is an example of a beautiful design - more advanced languages (dynamically and statically types) provide much nicer solutions to the same issue.

dougabug• 16 years ago

Insightful satire is one of the most illuminating forms of criticism.

jrockway2• 16 years ago

Seriously? This is more like, "I hate Java and teams with managers that like making diagrams instead of writing code".

Most procedural code is actually object-oriented. If you write:

    foo_t foo;
    init_foo(&foo);
    frobnicate_foo(&foo, "with a bar");
    cleanup_foo(&foo);

Guess what, that's object-oriented programming. You are ensapsulating state and behavior in a data structure and set of procedures. Calling that a "class" is just syntax sugar that a lot of people find useful.

Even the most die-hard anti-OO advocates write code like this. Why? Because it's a great way to manage complexity, and that's all programming is. Doing stuff, but also doing it in a way that is easy to change and easy to improve.

I'm not even going to comment on the rest of the article. It's clear that the author has never used an OO language other than C++ or Java, or a statically-typed language other than ... C++ or Java. Shockingly, there is a lot more to the world than C++ and Java.

encoderer5• 16 years ago

I'm not directly disagreeing, just, prodding in the direction of disagreeement... But..

In that example, where is the "encapsulation" you mentioned? The way I'm reading it, the only thing connecting the data with the behaviors is the fact that you just happen to call the functions and pass-in the data.

IOW, the is-somethings and does-somethings are separate.

shub• 16 years ago

All that ever happens is that you "call the functions and pass-in the data", except that OOP languages know to pass this for you. The difference between OOP-style C and an actual OOP language in this regard is syntactic, not conceptual.

br1• 16 years ago

Your code is object-based not object-oriented because of the lack of inheritance.

Xurinos• 16 years ago

His example is a little small to see how he would implement inheritance.

Also, inheritance is not a core requirement of OOP. Before you hit that downvote button, consider this: Inheritance allows your class to share attributes and behaviors with another class, and it allows code to recognize that instances of your class have those attributes and behaviors. In other words, when we say "is a", we really mean "does things that match the interface and meaning of". You can accomplish the same thing with "aspects" instead of "inheritance". Following that idea, it is simply a matter of introducing this simple API to add your behavior to an instance:

    add_aspect(&foo, 'Some Aspect Identifier');

And that's just the tip of the iceberg. Check out Art of the Metaobject Protocol (http://www.amazon.com/Art-Metaobject-Protocol-Gregor-Kiczale...) for some huge eye-openers.

TimJYoung• 16 years ago

I agree. Most OO implementations are simply the foo instance data combined with a pointer to a table of foo function/method pointers that keep the foo functions in a nice tidy location, Throw in some scoping rules enforced by the compiler as to who/what can access the foo instance data, and that's really all there is to it. The type-safety is basically the same as with procedural code - you can't pass a reference/pointer to foo to a function/method that expects a bar reference/pointer.

swift• 16 years ago

I agree with your complaints about the article, but the code example you give could be demonstrating programming with abstract data types in C just as well as it could be demonstrating programming with objects. In fact, unless frobnicate_foo is just a convenience function to look up a frobnicate function pointer in the foo_t structure and invoke it, I'd have to say that you're clearly demonstrating an ADT here.

metageek5• 16 years ago

>Another thing I hate is the way that everybody loves to hate the other guy’s programming language.

Oh, yeah, that never happens with non-OOP languages.

PatrickTulskie• 16 years ago

Should rename the article to "10 Things I Don't Understand About OOP"

tybris• 16 years ago

Hating OOP is a little old. It's not hard to understand that nothing is a silver bullet, except for silver bullets.

blahedo• 16 years ago

The poster writes: "Have you ever considered why it is so much harder to understand OO programs than procedural ones?"

It is? Seriously? I mean, there are badly-written OO programs, but there are badly-written programs of any variety, and assuming even a moderately good OO breakdown of the problem, the code in an OO program will fall into natural segments that are easy to see and easy to mentally file into compartments---much easier to read.

Furthermore, "written in C" and "OO program" are not mutually exclusive.

dkarl2• 16 years ago

100% free of original content, and much of what's there wouldn't qualify for an an anti-OOP "best of" list. I am really confused that he is an OOP guy who gave this talk at an OOP conference, because he seems quite sincere (not ironic) yet sounds like someone who is looking on OOP from the outside in or is being forced to do OOP against his will.

1: Nobody agrees on a definition for OOP, so it isn't clear what it actually is. Right, except that you have a clear enough idea of it to hate it, so...?

2: Hatin' on Blub. Many of those quotes came from fans of OOP, so I guess one of the things he hates about OOP is that OOP fans don't speak with proper reverence and/or community solidarity. What, should Bjarne Stroustrup consult the OOP marketing department before he makes a funny remark about C++? And the final quote from Stroustrup undermines his whole blog post. After reading that quote, I had to reread the whole post twice to see if it was tongue in cheek, but I don't see any irony at all.

3, 4, 5: It's legitimate to complain about classes, methods, and restrictive type systems, but within OOP you are able to embrace or eschew these things as you wish. Everyone knows this, right?

6, 7, 8, 9, 10: Not specifically aimed at OOP. These could all appear in a list of "10 things to hate about FP" if FP were popular in corporate software development.

It's especially ironic that he complains in #1 about the lack of a specific definition of OOP, but in 2-10 he paints a very restrictive, extremely overly specific picture of OOP. Programming with Java, UML, and design patterns and saying "I hate OOP" is like living in Los Angeles and saying "I hate California." LA is popular, but if you don't like LA, there's a hell of a lot more to see in California before you badmouth the whole state.

loup-vaillant3• 16 years ago

Incidentally, #1 is sufficient to hate "OOP" (the term), because using it will never lead to useful questions or answers.

Things to hate about OOP

Related Stories