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

[Jonathan Aldrich]

> Warning, this is a bit of a rant.

Rants are OK ;-).  But I wanted to respond to an issue that is 
technical, which may shed light on the general subject.


> Object-oriented, as constituted today, is just a layer of abstraction over
> imperative programming (or imperative style programming in functional
> languages, because objects require side-effects).

The idea that objects require side-effects is a common misconception. 
You can find a number of object-oriented abstractions that do not 
involve mutable state in commonly-used libraries.  If most 
object-oriented code is stateful, it's probably more or less because 
most code, in general, is stateful.


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).  In Cook's definition, "an object is a value exporting a 
procedural interface to data or behavior."  Each object conceptually 
carries its behavior with it as a set of procedures (methods), and the 
only way to interact with the object is to call one of them (via dynamic 
dispatch):

http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

You can write objects in just about any language (GTK+ and Microsoft's 
COM are good examples of objects in C) but it's quite awkward to do so. 
  A good working definition of an "object-oriented language" is a 
language that makes it _easy_ to define values exporting a procedural 
interface to data or behavior.  Likewise, you can do functional 
programming in C if you want, but it's a lot easier if you have language 
support in the form of lambda expressions, closures, etc.


Does the nature of objects, as expressed in Cook's essay, matter in 
practice for engineering?  I'm currently working on a paper exploring 
that question...it's not quite ready for public distribution, but if you 
are willing to look at a working draft and provide feedback, let me know 
privately.


 > What "object-oriented" language actually in use now isn't just
 > an imperative language with fancy abstraction mechanisms?

As a potential answer to your last question, Scala is beginning to see 
significant use.  It supports object-oriented programming, and has quite 
good support (and libraries) for both imperative and functional styles 
of programming.

Cheers,

Jonathan Aldrich