[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Alan Kay on the meaning of "object oriented"

Alan Kay certainly started with the idea of objects as being more "process-like" - which is why the Actors model his early work inspired is overwhelming concurrent. However, what he ended up with was Smalltalk, which looks more like the object-as-ADT model I described in my previous missive. It is not clear to me why that transition from process to ADT happened (if anyone else on this list knows, I'd be interested in hearing about it). Hewitt's Message- Passing Semantics group at MIT seems to have continued on with the highly concurrent approach to system design in the various actor languages that they developed, but none of those seem to have caught on the way that Smalltalk and its OO cousins did. Again, I don't know why.

I will split the remainder of this email into two sections, since we seem to be dealing with two separate issues here.

== OO and Concurrency ==

Adding concurrency to the object-as-ADT model is fraught with difficulty, largely due to the problems with mixing inheritance and active behavior to which you have alluded. OO seems to work well when used to arrange sequential computation (what you refer to as "the real computing"), but doesn't map as well onto concurrent computation unless you abandon things like inheritance. Indeed, the approach advocated by Meyer, and used in his Eiffel language, seems to involve using OO techniques to write individual sequential processes, and applying a more process-oriented approach to defining the interactions between a collection of OO processes. Mark Miller and the folks at Erights.org appear to have adopted a similar approach (sequential object computation within concurrent "vats" that communicate through events) in their E language for secure distributed programming. Both of these are examples of what I would consider a "good" synthesis of OO and concurrency, and neither of them seem at odds with what you described as your usual "design attack". I agree that there are a lot of nominally OO languages that don't get concurrency right, but that's a reason to condemn those languages, not the whole concept of object-oriented design.

== Other problems with OO ==

 But even that can get into trouble (dividing

Certainly, poorly designed classes and class hierarchies will introduce problems. A poorly designed process network will deadlock. That doesn't mean that all process-oriented programming is bad.

And the subtypes (which are
super-structures, i.e. structures containing more than the parent type
structures) become dangerous when STRICT analogy is not maintained.

Indeed, not maintaining substitutability in subtypes can also introduce problems. No argument there. Some people have even argued that OO itself is fundamentally flawed when it comes to substitutability (in that one must abandon much of what constitutes "OO" in order to achieve statically checkable substitutability). This suggests that care is required in developing OO systems. But care is also required in developing process-oriented systems.

As I mentioned previously, I am not an OO zealot. I think that the OO model can be useful. It is certainly popular, so it's useful to know about it, if nothing else. But it is not without its flaws. Whether you choose to use it is up to you. I have already pointed you to one of the books that I feel makes a good, reasoned case for the OO approach. I'm happy to point you to those articles I know of that present reasoned critiques of OO as well, if you would like to look at them. But I have no desire to carry out an extended argument about the merits of OO on this list.


On Nov 15, 2007, at 7:54 AM, tjoccam@xxxxxxxxxxx wrote:

Hi Larry,
One of the better descriptions of objects and classes I've seen comes
from Bertrand Meyer. He describes classes as "abstract data types
equipped with a (possibly partial) implementation". An object is a
run-time instance of a given class. So, while you are correct that an
object is in most cases basically a data structure and some
associated procedures, that rather misses the point. The key aspect
of objects is that they are not just arbitrary data structures with
arbitrary procedures, but instances of a type (the class) with a
prescribed interface. The OO approach involves designing software
that is (ideally) implemented as a collection of interacting ADT
implementations. Although it's certainly possible to implement
abstract data types in non-OO languages, an OO language provides
facilities for controlling encapsulation, treating implemented ADTs
as modules, treating ADTs as types within the type system, safely
constructing and manipulating ADT instances to preserve invariants,
and for defining certain ADTs to be subtypes of other ADTs via
inheritance (which in turn allows objects that are instances of the
subtype to be treated as instances of the supertype when appropriate,
and to do so in a type-checked manner).

This pretty much fits what I understand - and does not fit the Alan Kay notion (which is more like a process). Where the OO stuff makes sense is
in clear analogies --- for instance, mathematical types (which can be
generalized to more than the bit size of the processor, or even unlimited bit size - or oddball bit size - and still naturally have "methods" such
as addition and multiplication that exhibit clear analogy in their
behavior, e.g. overflow). But even that can get into trouble (dividing
matrices?). And the key to the mathematical objects is they have a very
well defined usage of resources (i.e. just CPU and memory, and if done
carefully, limited scratch such as stack). And the subtypes (which are
super-structures, i.e. structures containing more than the parent type
structures) become dangerous when STRICT analogy is not maintained.

I don't particularly want to get into all of the arguments for the
use of an OO approach. I think that Bertrand Meyer presents a good
case for developing software based on classes and objects in his text
"Object-Oriented Software Construction", and I encourage you to dig
up a copy of that book if you want to get a better idea of what all
of the fuss surrounding OO is about. Note, however, that what Meyer
describes is how things *should* be done in OO development, not
necessarily how what passes for OO development in many organizations
is actually done. It's probably also worth noting that many of
Meyer's arguments are probably equally applicable to a process-
oriented design approach, and that the approach to OO concurrency
advocated by Meyer is explicitly influenced by CSP (both CSP and
occam get several mentions in his book).

I think OO and processes are actually orthogonal, with OO (as you defined
it) being a technique for organizing (abstract) data assemblages, and
processes (or Kay's objects) being a way of organizing (concrete)
resources. Unfortunately OO is made to expand to include state machines (open, read, malloc, etc). Then inheritance becomes metaphoric and not analogical (hidden side effects, differences in behavior, dependencies). OO (or any other data organization technique) should be a layer on top of the process harness. That has always been my design attack: get the data flow working with completely unrestrictive "null" algorithms or methods
(doing nothing except, possibly, forcing delays equivalent to the real
task); then, once that is robust, do the (comparatively easy) task of
adding the real computing.

Larry Dickson