[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
Paulo Sérgio Almeida
psa at di.uminho.pt
Fri Apr 19 12:51:23 EDT 2013
On 4/19/13 2:34 PM, Greg Morrisett wrote:
> [ The Types Forum,
> http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
>> William Cook's Onward 2009 essay makes an argument, which is convincing
>> to me and to many others in the OO community, that the distinguishing
>> characteristic of objects is dynamic dispatch (a.k.a. subtype
> I do agree that the abstraction mechanisms used have little
> or nothing to do with state and identity, which is also
> typically confused with the whole "OO" mantra. It's perfectly
> reasonable to do value-oriented programming with first
> class ADTs. Happens in both Haskell and OCaml all the time.
Yes, abstraction mechanisms have little to do with state and identity.
Yes, one can program with abstractions and values, mostly avoiding state
This does not mean state and identity are not relevant characteristics
of object oriented programming.
There are several characteristics of objects and object oriented
One is object in the duality Object/ADT very well presented in Cook's
essay "On Understanding Data Abstraction, Revisited". This paper should
be read by anyone interested in the subject. But I would say it is not
*the* distinguishing characteristic of objects, but *one* (although a
very important) one. This is what most interests type theorists.
But there is another characteristic. Object in the duality Object/Value
as presented in e.g., "Values and Objects in Programming Languages" by
MacLennan. Which has to do with the "state and identity" feature of
objects. This lies in the "object as entity of a model" and the origin
of OO in Simula, and later reused in other OO languages.
And this second characteristic of OO is not just about imperative
programming or mutable state, it is about the promoting of *shareable
mutable state*, where an object, with a given identity, after receiving
a message and changing state, because it is known by other parts of the
system, will affect those parts, possibly without that being immediately
aparent. Some even say that the most pure form of OO is the actor model.
One influence of OO is the promoting of parameter passing by "identity
passing" as the norm, with the terrible effects due to surprising
aliasing of shared state that occur. Even in classic imperative
languages with mutable state, the norm was to pass values; when passing
references to "objects", typically a more controled stack discipline was
the norm. Sharing mutable state in an unrestricted way was already known
to be dangerous; languages like Euclid tried to do something about it;
in many cases pointers to heap allocation were only used if recursive
data structures were needed. Many pointers were only to "borrow" the
object in a restricted scope.
OO languages changed the norm to be: use references everywhere, start
with null references, allocate on the heap. And this was also motivated
by subtype polymorphism / heterogeneous containers. Always having
variables as references facilitated this. But this easy path neglected
the dangers posed by the too easy way in which one can share mutable
state, sometimes accidentally, and by the false sense of security given
by having garbage collection, as opposed to what happens in functional
languages were the user sees only values. I would say that one defining
feature of OO was the way in which people ended up overusing objects and
identities, when values would be more appropriate. In fact by people
thinking less about values than even in classic *imperative* languages,
like FORTRAN and C. This point of overusing identities is well made in
some of Rich Hickey's talks about Clojure.
This second characteristic of OO, and the failure of mainstream OO
languages to provide mechanisms to properly provide state encapsulation
can become its bane if nothing is done about it. Fortunately many people
started doing something about object aliasing, state encapsulation,
object ownership. (I did my 2 cents ... some years ago.) A language
which aims for mainstream use, but worries about this aspect is Rust.
So, my point is that the OO paradigm, *de facto*, depicted in languages
like Simula, Smalltalk, and Java, is the combination of at least these
two aspects. Saying that only one is the defining characteristic is not
an accurate description of reality.
This does not mean that OO is a "good thing", nor that some of these
things cannot be picked and mixed, obtaining languages that combine,
e.g., the abstraction characteristic of objects with functional
programming (but can one really call such language OO?), or languages
that are multi-paradigm (like Scala and Rust), that support both Objects
and ADTs (in that aspect) and both Values and Objects (in the other
aspect) and both functional and imperative programming styles.
This is indeed the future and talking about paradigms is so passe ...
More information about the Types-list