Taboo "OO"
loup-vaillant.fr
loup-vaillant.fr
- 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).
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.
Regarding inheritance, I did say that I do not consider it to be mere syntactic sugar.
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.
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.
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.)
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.
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...
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.
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.
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.
Obviously my interpretation is no more authoritative than anyone else's :(
Similarly, you can use a language that claims to be OO and ignore and of those features and write purely procedural code.
"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.
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...
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.
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.
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".
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.
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.
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.
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.