[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages

[Paulo Sérgio Almeida]

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
>> polymorphism).
...
> 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.
>
> -Greg
Hi all,

Yes, abstraction mechanisms have little to do with state and identity.
Yes, one can program with abstractions and values, mostly avoiding state 
and identity.
This does not mean state and identity are not relevant characteristics 
of object oriented programming.
There are several characteristics of objects and object oriented 
programming:

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

Regards,
Paulo