

Taboo "OO" - loup-vaillant
http://www.loup-vaillant.fr/articles/taboo-oo

======
danieldk
Following the reasoning of the author, it can be argued that structured
programming is syntactic sugar for machine language. It is besides the point,
because OO certainly means something to a programmer. Do a 'paradigm-test'.
Ask a programmer to implement a program in four paradigms:

\- Object-oriented

\- Structured

\- Functional

\- Logic programming

and he is likely to come up with four different programs. Pass these programs
on to another programmer, and ask her to categorize these programs by
paradigm. She will probably use the same categorization.

Programming paradigms are abstractions that may be somewhat overlapping, but
have unique traits, and possibly world-view (everything is an
object/operations on structured data/expression/predicate).

~~~
JoachimSchipper
The article argues that "sys.stderr.write("Hello world")" is not meaningfully
different from "fprintf(stderr, "Hello world");" - sure, they are recognizably
different, but the difference is only "skin-deep" (and the term "OO" confuses
more than it clarifies - do you mean "good", "with proper encapsulation",
"written in typical Java style"?)

------
jerf
Objection orientation is a property of the _program_ , not the language.
Implementing inheritance in C is not a contradiction, it is using OO in C.
With great enough effort, one can use OO anywhere. Even Haskell could be
beaten into submission. It may not be slick and you may be fighting the
environment tooth and nail, but it can be done in any Turing Complete
environment.

This is true for any particular definition OO. You can implement prototype-
based OO in Java. You won't have help from the language or the libraries, but
there's nothing actually _stopping_ you.

"Functional" is also a property of a program, and not a language. "Immutable
data" is a property of the program, and not the language. After all, it's all
machine language in the end.

~~~
loup-vaillant
You're right. What gave you the impression that I thought otherwise? (I'm
serious, I really want to know. I may even modify my essay.)

Regarding inheritance, I did say that I do not consider it to be mere
syntactic sugar.

~~~
jerf
It's more that I assume that people think OO is a property of a language until
proved otherwise, and your essay did not give me the impression that you
thought what I said. Especially the part with the C and C++ code where you
deny the C code is OO: "Some of you may conclude that the C program is
actually OO because it instantiates a data structure. No. The only alternative
would be global variables. That would mean that any properly structured
procedural program is OO as well." And I disagree. The C code is simple OO
code, but it's OO, simple or otherwise. Here is a class. Here are the methods.

Besides, _ALL_ software engineering terms of significant are ill-defined.
Strong typing. Functional programming. I can even come up with two distinct
meanings of immutable. If we apply the "there must be one clear meaning or the
term's useless" we might as well give up discussing software, though the point
that one must actually define which term you're using if you're going to have
a serious discussion is still a good one.

I would also agree that the term OO has been not merely used as a
characteristic of good design, but gotten itself _defined_ as good design in
some circles, such that attacking or even trying to refine the term OO gets
perceived as an attack on the goodness of the language. Ask a Ruby partisan
why it's better than Python and a good bit of the time you'll hear about how
it's More OO than Python and Therefore Better, where it simply goes without
saying that Being More OO Is Better, even though in practice the places where
Python is "less OO" are not a problem, actually have their reasons, and for
certain other definitions of OO are actually _more_ OO. (len is a function
that consumes generic _interfaces_ to create its result. This is not a
particularly "not OO" way of doing things.) See also MVC, where almost
unlimited damage will be done to the term to show that something is "MVC",
because MVC ===== Good Design.

~~~
loup-vaillant
> _The C code is simple OO code, but it's OO_

Pretend "OO" doesn't exist, and OO hasn't been identified. (Say we're in the
70's, that should more or less do it). Would you say my C code is procedural?
Structured?

> _Besides, ALL software engineering terms of significant are ill-defined._

I agree. "OO" just seemed worst.

> _I would also agree that the term OO has been […] defined as good design in
> some circles_

Excellent point. That's one thing that pissed me off, actually. I probably
should add a paragraph about that.

~~~
jerf
"Pretend "OO" doesn't exist, and OO hasn't been identified. (Say we're in the
70's, that should more or less do it). Would you say my C code is procedural?
Structured?"

Begging the question, no offense.

I don't address the other two points because I agree, but I didn't think that
should pass in silence. (Though I gotta tell you MVC is in the running for
worst-mangled-term too, but I won't push the point.)

------
narag
Some good points, I know where you're coming from, but when I read this:

 _This sounds like typical OO. It is, but in practice, it's little more than
plain old procedural programming with syntactic sugar._

...it makes me think that syntactic sugar is undervalued, or maybe that some
very useful and important procedural programming practices are now placed
under the OO label.

~~~
loup-vaillant
Both, actually.

A computer engineering professor once told me that OO was about instantiation.
In procedural code, you would have only one point, probably held in a global
variable. My C code would look OO to him.

Chris Okasaki once wrote a programming language for one of his CS classes. For
whatever reason, he chose to make indentation mandatory, and he got rid of
semicolons and curly brackets. The result strongly suggests that beginners are
more influenced by such syntactic sugar, rather than by deeper properties,
like type inference. [http://okasaki.blogspot.com/2008/02/in-praise-of-
mandatory-i...](http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-
indentation-for.html)

~~~
Retric
IMO, OO programming is using internal API's to split programs into smaller
pieces that have both data and code and talk to each other by passing
messages. From that perspective inheritance is simply extending an API with
another API that has new behavior and uses the existing API etc.

So, while syntactic sugar helps with bookkeeping, OO is a programming
technique not a language feature. With great discipline you could write OO
code in C, but languages that pick up the slack help you write clean code
faster and avoid the temptation, late at night, to use "goto" that one time it
really helps. (<http://xkcd.com/292/>)

PS: This is from the perspective of someone that came to OO later on. I think
people who are taught OO programming early have trouble separating the how
code using the abstraction from what it actually is.

------
Miky
His example of C vs C++ doesn't take advantage of virtual
functions/polymorphism at all, which is a much more significant part of the
"syntactic sugar" that C++ adds over C, and is what I would say makes it OO.

So what if it's "just" syntactic sugar anyway? Calling functions in C is just
syntactic sugar on top of messing with the stack. You could make the claim
that any feature of any programming language is just syntactic sugar on top of
something lower-level, eventually getting down to the circuitry. But that's
not a terribly useful criticism.

The definition of OO to me is a certain kind of polymorphism, which is fit by
class hierarchies in Java, Ruby, etc., multimethods in CLOS, and typeclasses
in Haskell (although Haskell in general isn't OO), although of course, that's
not an authoritative definition either.

~~~
loup-vaillant
First paragraph: you're right. That's why I explicitly said that subtype
polymorphism isn't mere syntactic sugar.

Second paragraph: that, is past the limit of what one could reasonably call
"syntactic sugar". Now I only have an intuitive idea of which compilation
process is syntactic sugar, and which is not. I feel however that we could
find a nice mathematical definition that nearly everyone will agree with.

------
EliRivers
I always thought OO was a design philosophy rather than a set of tick boxes
that a programming language/notation must provide. Design in OO, code in
whatever you like, but note that some programming languages make it easier
than others.

Obviously my interpretation is no more authoritative than anyone else's :(

~~~
numeromancer
Great. Now we can argue over what a "design philosophy" is, and whether OO is
one.

~~~
EliRivers
Awesome. It's your idea, so you can go first :)

~~~
numeromancer
No thanks. I'll leave such questions to the pointy-headed meta-academics. I'm
a practical philosopher, and I pick the epistemological tools which best fit
the job-at-hand, and which give me the most bang for my buck.

------
ollysb
Crikey, where to start... I've had several stabs at this response exploring
abstraction and data hiding, message passing, keeping computation close to the
data... In the end OO just seems like a philosophy with some related
principles rather than something with a concrete definition.

------
PaulHoule
I think this is bogus.

"OO" thinking is critical to API design. Think of, say, common LISP or PHP,
both languages which have had OO functionality bolted on. The 'standard
libraries' in both CLISP and PHP are quite comprehensive, but are just piles
of functions that appear disorganized in comparison to the 'standard library'
of a more OO language such as C# or Ruby.

Sure, you can write C code that implements "OO" in the same way that C++ does
under the hood... All real languages are turing complete, so you can say that
'syntactic sugar' is the ultimate difference between COBOL and Haskell...
Whatever you call it, OO is a powerful organizing principle.

~~~
loup-vaillant
I said two things: (1) class based programming isn't much different from plain
old structured programming. (2) "OO" sucks.

I did _not_ however, said that OO sucks. In pompous words, the quotation isn't
the referent.
[http://lesswrong.com/lw/ok/the_quotation_is_not_the_referent...](http://lesswrong.com/lw/ok/the_quotation_is_not_the_referent/)

Also, my C code wasn't meant to be class based in C, only idiomatic C. That is
my point: idiomatic C (which is procedural, structured) often strangely looks
like class based code.

~~~
PaulHoule
Sure.

But the funny thing is that using an OO language shapes the way you use
procedural languages.

Owen Taylor, who worked in the same research group as me for a semester and
who is one of the core developers of GTK, is somebody who believes (or used to
believe) that "OO sucks" in the sense that they made a conscious decision to
code GTK in straight C, not C++. That said, the actual organization of GTK is
shaped by OO ideas.

On the once in a blue moon that I write some C that isn't just simple
procedure "glue code", my C coding style is heavily influenced by my OO
experience, in the sense of how I name things and I frequently end up passing
'this' as the first arguments to functions. I think of the old C++ compilers
that just outputted C code with mangled names... That's how I write C, except
the names aren't so mangled.

------
zwieback
You aren't "topmind" in disguise, are you? Just kidding.

You make some good points and I take it you don't have an issue with a
particular language, just the overuse of the term "OO". I think the argument
would be more effective if it didn't use overly simplified C and C++ samples.
Instead, focus on what makes a software design "OO" and what doesn't. The
language is largely irrelevant.

Also, I think the term "syntactic sugar" is problematic - I didn't like it the
first time I heard it and still don't. Isn't everything syntactic sugar? Also,
these days if you're trying to be vaguely insulting it might be better to say
"syntactic high fructose corn syrup".

~~~
loup-vaillant
"Syntactic sugar" is a term for which I do not have a suitable, technical
definition. I feel we could find a satisfactory one, however. If not, I may
have to taboo that term as well.

------
hxa7241
> We should stop using the term "Object Oriented". I see two reasons: first,
> "OO" means too many things to too many people. Second, the most popular
> definition of OO is essentially about syntactic sugar.

1, there is a good enough concensus: would people not broadly agree that C is
not really, and that Ruby is, and that OCaml is a bit, and so on?

2, you cannot simply dismiss something as syntactic sugar. Representation for
humans is half of the whole purpose of programming languages.

------
DanielRibeiro
Reminded me of Scala's creator Martin Odersky discussing what it is to be a
functional language, on his article _"A Postfunctional Language"_ :
<http://www.scala-lang.org/node/4960>

------
kenjackson
Honestly, more people agree on the term OO than functional. And the term
functional has evolved much more over time than OO has. I just didn't find
anything in the argument extremely compelling.

And statemens like, "For instance, by Alan Kay's definition, Erlang, a
functional concurent language, is more OO than C++." w/o any evidence, I find
suspect.

~~~
loup-vaillant
What about the fact that all Erlang revolves around thingies (the processes)
that send messages to each other?

~~~
kenjackson
Erlang may well be more OO than C++, but I would have liked to have seen you
back this up with evidence.

First take Alan Kay's definition, and then show how Erlang is more OO than
C++. Would take a paragraph or two, but would add a lot of credibility, IMO.

It's not that I doubt your thesis, but your lack of evidence leaves me
wanting.

~~~
loup-vaillant
Noted. I'll think about that, or a better link.

------
T-zex
I think the presented design is broken in C++ example. Point should remain a
structure (it would be even more efficient in a runtime) and a new object, say
Brush, should be responsible for drawing on some Canvas. Then you could see
the benefits of OO like drawing on different types of Canvas with different
Brushes using the same Points.

~~~
loup-vaillant
Yes, but the same could be done in C: just make several compilation units, one
per Canvas (or put several canvas in the same files, if they are small
enough).

Now if you thought of using a Canvas without determining a which one before
hand, _then_ you need subtype polymorphism, a much more significant feature,
of which I do see the benefits.

------
fauigerzigerk
Not that it's particularly important for the point you're making, but your C
code has quite a number of bugs. structs don't copy implicitly in C and even
if they were the move function wouldn't move the original Point. Sorry for
nitpicking... ;-)

------
hetman
I would like more details on how subtype polymorphism is equivalent to
closures.

