38 ms·

Taboo "OO"

50 points by loup-vaillant 16y ago

narag 16y ago
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 16y ago
  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-indentation-for.html http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-i...
  - arethuza 16y ago
    The strategy code has for instantiating things sounds orthogonal to OO-ness to me.
  - Retric 16y ago
    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/ 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.
ollysb 16y ago
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.
EliRivers 16y ago
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 16y ago
  Great. Now we can argue over what a "design philosophy" is, and whether OO is one.
  - EliRivers 16y ago
    Awesome. It's your idea, so you can go first :)
    - numeromancer 16y ago
      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.
- arethuza 16y ago
  Application or library design can be object-oriented even though the underlying implementation language isn't - it's just rather easier to do if the language does have direct support for some OO features. Similarly, you can use a language that claims to be OO and ignore and of those features and write purely procedural code.
- coliveira 16y ago
  Your idea makes sense, but historically OO design came after OO languages. It was a big part of the hype promoted by tool makers during the 90s.
Miky 16y ago
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 16y ago
  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.
T-zex 16y ago
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 16y ago
  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.
DanielRibeiro 16y ago
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 http://www.scala-lang.org/node/4960
danieldk 16y ago
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 16y ago
  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 16y ago
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 16y ago
  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 16y ago
    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.
PaulHoule 16y ago
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 16y ago
  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 16y ago
    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.
kenjackson 16y ago
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 16y ago
  What about the fact that all Erlang revolves around thingies (the processes) that send messages to each other?
  - kenjackson 16y ago
    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 16y ago
      Noted. I'll think about that, or a better link.
fauigerzigerk 16y ago
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... ;-)
zwieback 16y ago
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 16y ago
  "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 16y ago
> 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.
hetman 16y ago
I would like more details on how subtype polymorphism is equivalent to closures.

50 points by loup-vaillant 16y ago

narag 16y ago

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 16y ago
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-indentation-for.html http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-i...
- arethuza 16y ago
  The strategy code has for instantiating things sounds orthogonal to OO-ness to me.
- Retric 16y ago
  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/ 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.

ollysb 16y ago

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.

EliRivers 16y ago

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 16y ago
Great. Now we can argue over what a "design philosophy" is, and whether OO is one.
- EliRivers 16y ago
  Awesome. It's your idea, so you can go first :)
  - numeromancer 16y ago
    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.
arethuza 16y ago
Application or library design can be object-oriented even though the underlying implementation language isn't - it's just rather easier to do if the language does have direct support for some OO features. Similarly, you can use a language that claims to be OO and ignore and of those features and write purely procedural code.
coliveira 16y ago
Your idea makes sense, but historically OO design came after OO languages. It was a big part of the hype promoted by tool makers during the 90s.

Miky 16y ago

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 16y ago
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.

T-zex 16y ago

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 16y ago
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.

DanielRibeiro 16y ago

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 http://www.scala-lang.org/node/4960

danieldk 16y ago

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 16y ago
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 16y ago

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 16y ago
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 16y ago
  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.

PaulHoule 16y ago

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 16y ago
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 16y ago
  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.

kenjackson 16y ago

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 16y ago
What about the fact that all Erlang revolves around thingies (the processes) that send messages to each other?
- kenjackson 16y ago
  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 16y ago
    Noted. I'll think about that, or a better link.

fauigerzigerk 16y ago

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

zwieback 16y ago

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 16y ago
"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 16y ago

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

hetman 16y ago

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