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

[Jason Wilkins]

Thanks Jonathan for the information.  I was not completely confident that I
was correct about objects and side effects, but almost every definition of
an "object" I've read heavily implies that they contain state.  How else
can you bind state and methods together if there is no state ;-)  Perhaps
the common definition is misleading.

But I say this before reading your link.


On Thu, Apr 18, 2013 at 6:48 PM, Jonathan Aldrich <
jonathan.aldrich at cs.cmu.edu> wrote:

> [ The Types Forum, http://lists.seas.upenn.edu/**
> mailman/listinfo/types-list<http://lists.seas.upenn.edu/mailman/listinfo/types-list>]
>
>  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<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
>