[TYPES] The type/object distinction and possible synthesis of OOP and imperative programming languages
jonathan.aldrich at cs.cmu.edu
Thu Apr 18 19:48:50 EDT 2013
> 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
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
> 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
More information about the Types-list