
Objects, Identity, and Concept-formation (2008) - 1781
http://blog.higher-order.com/blog/2008/12/04/no-such-thing/
======
kazinator
"Object-oriented programming" in its basic form means that the data
manipulated in a computer program is self-describing. We can ask a datum,
"what are you? what type?". The functions of that program are organized around
data. This is in contrast with the form of programming in which data is just
some storage, which is given a meaning by the algorithm that operates on it;
it is not self-describing.

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

~~~
l_dopa
You just described parametric polymorphism, which has nothing to do with
objects or runtime type information.

~~~
kazinator
"has nothing to do" ... says you! I didn't describe static parametric
polymorphism. Some of the things I described are doable with static parametric
polymorphism in some limited circumstances.

~~~
l_dopa
Well, you described parametric polymorphism (a generic Nth function) and then
switched to talking about dispatching on tags at runtime. You are mistaken;
those really are completely unrelated concepts.

------
TelmoMenezes
The term "object-oriented" was coined by Alan Kay, and he did provide a much
more precise meaning. Unfortunately, the term became a fad and was then
diluted into all sorts of vaguely related ideas.

[http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented](http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented)

I find the original idea deep and worth thinking about.

~~~
techadv
The page you link seems to indicate that Kay _didn 't_ propose this as a
definitive definition of OOP, but rather as a description of the defining
features of Smalltalk. I'm not familiar with the document; do you have any
insight?

~~~
TelmoMenezes
You are right. I've heard Kay provide short definitions. One documented case:

"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...](http://userpage.fu-
berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

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.

------
calvins
"Valid concepts are arrived at by induction."

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](http://en.wikipedia.org/wiki/Prototype_theory)
seems a much better starting point for thinking about concepts in general, and
'* programming' in particular.

~~~
techadv
The author's case is based upon Harriman's account of induction in the natural
sciences. I don't think that's appropriate here. Computer Science -- or at
least PL/Software Engineering -- is not a physical science! In many cases it's
not or historically wasn't even a mathematical science.

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

~~~
mbrock
I was happy to see a blog about the intersection of functional programming and
philosophy, but I'd be happier if it weren't Objectivist. On the other hand,
it's nice to see that my Rand radar is working. At the first mention of
"actual concepts," I was a little intrigued. Then I noticed arrogant
statements like "abstraction that is made in error," and the typical retreat
to Aristetolian epistemology in order to make some basically political point.
Then I went back and noticed that the link to "epistemology" actually links to
"Objectivist epistemology" and that the citation for the criteria of
concepthood is from The Objective Standard ("Reason, Egoism, and Capitalism").

------
InfiniteRand
Well, the author recommends induction as a means of figuring this out, and it
seems for induction to work we need to have some existing example to induce
the principle from (if I am remembering my maths, I might not be). So to
figure out our concept it may be worth taking a look at what the use of
object-oriented features is, and use that as a starting point. Maybe, again I
am a little rusty on my inductive reasoning.

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.

~~~
techadv
The article author was referring to inductive reasoning in the sense of
epistemology, which is _not_ the same as mathematical induction. In fact,
mathematical induction is a _deductive_ reasoning technique.

Here's the relevant wiki article:
[http://en.wikipedia.org/wiki/Inductive_reasoning](http://en.wikipedia.org/wiki/Inductive_reasoning)

~~~
jorgis
You might also refer to this as "recursion" when talking about computer
programming.

------
techadv
The mainstream programming language community has a pretty strong consensus on
what OOP means, in terms of language features.

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.

~~~
yummyfajitas
_Edit for downvotes: dynamic dispatch + associating methods with classes..._

So Julia and Clojure are object oriented? Some "object-oriented" julia code:

    
    
        f(x: Int64) = ...
        f(x: String) = ...
    

Even Haskell might qualify, due to existential types.

[http://www.haskell.org/haskellwiki/Existential_type](http://www.haskell.org/haskellwiki/Existential_type)

~~~
techadv
I have no idea how defining the type of a function's domain is supposed to be
indicative to dynamic dispatch or associated methods with classes. I think I
don't understand your example :-( Perhaps you can elaborate, since I don't
know much about either of these languages.

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.

~~~
yummyfajitas
Julia/Clojure/Lisp does dynamic dispatch on the argument types of the function
- it's called multimethods. So it seems to fit your criteria of "dynamic
dispatch + associating methods to classes".

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.

~~~
techadv
Great, thanks! Your example makes a lot more sense now.

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

------
kazinator
There is such a thing as object-oriented programming; the author just hasn't
encountered it through the tools that he was led to believe were OO
programming tools.

"I didn't find Tao in Java or GoF" does not imply "there is no Tao".

------
audionerd
Alan Kay coined the term "object-oriented" for software architecture in the
late '60’s. He offers a good explanation of it:
[http://programmers.stackexchange.com/a/58732](http://programmers.stackexchange.com/a/58732)

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

------
mpweiher
[http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html](http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html)

------
dang
Url changed from [http://runarorama.github.com/blog/2008/12/04/no-such-
thing/](http://runarorama.github.com/blog/2008/12/04/no-such-thing/), which
redirects to this.

------
a3voices
Programming in C which isn't "object oriented" is very similar to say, Java.
You make the same architectural diagrams on a whiteboard for both. So I agree
with the author.

~~~
gress
Java is a deeply flawed object oriented language. You agree with the author
because, correctly, you are experiencing that Java barely supports object
oriented programming. Not that there is no such thing.

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

