Objects, Identity, and Concept-formation (2008)
blog.higher-order.com
blog.higher-order.com
Self-describing data lets us then have generic operations. For instance, if an object hold a sequence of other object, we can create an operation which extracts the N-th one. And we can make that same operation work for an object which is a character string, vector, list. This is because the function can inquire the object what it is, and then call the appropriate concrete implementation which does the right thing for that type.
This leads us to realize that type is connected to the operations which are applicable. Those objects are somehow of the same "kind". This gives rise to the concept of subtyping and substitutability: a string is a kind of sequence and so is a list and we can have operations on sequences.
The non-object-oriented concepts are all that cruft from various languages which tries to strangle OO: virtual base classes, protected members, methods within class scope, scope resolution, copy constructors, yadda yadda ad nauseum ... We are led to believe that OO requires this or requires that. It's not OO if there is no encapsulation. It's not OO if there is no language-enforced "information hiding". It's not OO if there is no private/public access mechanism. It's not OO if method calls aren't represented as message passing. It's not OO if methods aren't in a compile-time class scope together with data members. ...
My bet is even Smalltalk programmers don't think of eggs as knowing how to scramble themselves; but eggs do have an API, a behavior, that makes them distinct from other kinds of objects and at the same time shares characteristics with other objects, such as weight and dimensions.
I can assemble a list of eggs, elephants, and cars, and write "take the sum of the weights of all the objects". Although these objects are of different kind, they share a common characteristic that would be exploited naturally by any language user. Exploiting multiple "views of a thing" is a feature of English ("natural language") and to my mind is a feature of any successful "generic programming" computer language.
Processes communicating by asynchronous message passing is a better simulation of the familiar world; but that vision is not realized by Smalltalk, wherein messages are passed synchronously. What we want from language is the ability to write powerful sentences and have them mean something to the machine -- as long as the computer and human agree on the meaning. The better part of this power comes from a sophisticated treatment of type and generic operators.
Deleted comment
http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented
I find the original idea deep and worth thinking about.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
If you read this email, you will see that what he had in mind was much more than a way of programming. It was a model of computation where the computer is a networks of "cells" exchanging messages.
Message passing can be synchronous, and function calls asynchronous
Also consider remote procedure calls.
If the point is to argue that OOP is not a valid concept, the author should show first that 'programming' is a valid concept (using the same definitions) and that there are some related concepts (e.g., 'functional programming') that are valid, because if the same argument can be applied to most or all other '* programming' concepts too (not to mention concepts like 'validity' and 'concept'), then the point is not specific to OOP at all.
Incidentally, http://en.wikipedia.org/wiki/Prototype_theory seems a much better starting point for thinking about concepts in general, and '* programming' in particular.
Furthermore, all programming paradigms suffer the same fate in popular/industry press (even if not within academic communities). For instance, productivity claims justified by the macros and dynamic typing of Schemes and Lisps are often implicitly cross-applied to MLs under the broad header of "FP". And vice-versa for safety claims about MLs germane to types.
Sure, some people are careful about this sort of thing. But some aren't, which can make the concept of FP a "grab-bag" in certain settings. That doesn't (or shouldn't) make FP a "non-concept".
(It appears you beat me to this punch, so I'm moving my comment here instead of fragmenting this point into 2 top-level comments.)
I think one thing that strikes me with Object-oriented programming in general is the idea of data management and function management.
I guess if we look at the features that are associated with object-orientation (I am not pretending that I am being strictly inductive at this point, although I think this is vaguely inductive), I would say that it takes the management and organization of programming concepts, such as data and function organization, and embeds it into the language itself.
Here's the relevant wiki article: http://en.wikipedia.org/wiki/Inductive_reasoning
Some people out there seem to have some confused notions of what OOP is. That doesn't mean there isn't a well-understood and more-or-less accepted definition, at least in academia.
Edit for downvotes: dynamic dispatch + associating methods with classes, often times but not necessarily accompanied by an inheritance hierarchy. Of course there's lot of room for design decisions (and prototype-based languages are only awkwardly encapsulated in that group), but these features are basically unique to OOP languages.
The point is that you could put a language with these features in front of any random sample of PL researchers and they would probably more-or-less agree on whether the language has OO features. That's more or less the definition of scientific consensus.
So Julia and Clojure are object oriented? Some "object-oriented" julia code:
f(x: Int64) = ...
f(x: String) = ...
Regarding existential types: yes, there's an intimate relationship between existential quantification and OOP. But you can distinguish the difference between OO languages and (non-OO languages with existential types) in the type theory. That's what's important. I think the raw empirical nature of my academic community consensus test is far preferable to the author's epistemological argument.
The question is whether OOP has meaning. I think if the PL community can be empirically demonstrated to have enough consensus that languages are reliably categorized as OO or non-OO, then we can safely say the term has meaning regardless of any armchair philosophy to the contrary.
Edit: And I think (hope) the author of the article would agree my test is sufficient. He states: When I say that there’s no such thing as OO, I mean, more precisely, that there exists some abstraction (or several) that is referred to as “object-oriented”, but that this abstraction has no actual referent in reality. It is an abstraction that is made in error. It is not necessary, and serves no cognitive purpose. It is “not even false”..
If OO has enough meaning to an important subgroup of people that they can use it with more-or-less consensus, then the claim that it has no referent in reality is clearly empirically denied, at least for that subgroup. And if that subgroup happens to be a large chunk of the PL community, then I think that's an important enough subgroup to settle the larger question.
And in some sense, it is used for object orientation - CLOS is built on it. But on the other hand, these languages are very far from what one would normally normally call "object oriented".
I do agree with you that there is some meaning to the term "object oriented" - I often completely understand what is intended by the term. Python is certainly OO, Haskell is almost certainly not. But to some extent I agree with the author - it would be very useful to have a precise definition, because I don't think that classifying stranger languages as OO is that reliable.
The easy way out is to say that these languages are OO in the same sense that Java is functional. Easy but maybe not unfair, particularly since all are dynamically typed.
The clojure examples make this look like OO. I would have to find a formal definition of the semantics to figure out if there's a more nuanced explanation than the easy one above.
And yes, I think I agree with the last bit. The author's observation that lines can become blurred is certainly valuable and true. It's the author's conclusion that the term OOP is therefore meaningless which is, imo, empirically false.
edit: stray punctuation
The CLOS design absolutely nails OO, and that's even before we look at the meta-object protocol.
Then code using that dispatching to implement behavior would be object-oriented, I think.
If not then no.
Also it's code that's object oriented or not, a language 'being' object oriented is a discussion of how well it supports such a thing. But they're all turing compatible; with enough abstraction you can write any type of code on top of any language.
"I didn't find Tao in Java or GoF" does not imply "there is no Tao".
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” — Alan Kay
It's easy to assume only languages with Class and Object abstractions are "object-oriented", but the "orientation" is really more about your mental model of the system as differentiated objects that communicate via messages.
[edit: Why the downvotes? I'm not saying java is bad - just that it isn't a strong representation of object orientation. If you take Java as the examplar of object orientation, then you will reasonably conclude that Object Orientation is a weak concept.]