TITLE: Alan Kay on "Real" Object-Oriented Programming
AUTHOR: Eugene Wallingford
DATE: September 20, 2010 4:28 PM
DESC:
-----
BODY:
In Alan Kay's latest
comment-turned-blog entry,
he offers thoughts in response to Moti Ben-Ari's CACM
piece about object-oriented programming. Throughout, he
distinguishes "real oop" from what passes under the term
these days. His original idea of object-oriented software
is really quite simple to express: encapsulated modules
all the way down, with pure messaging. This statement
boils down to its essence many of the things he has written
and talked about over the years, such as in his
OOPSLA 2004 talks.
This is a way to think about and design systems, not a set
of language features grafted onto existing languages or
onto existing ways of programming. He laments what he
calls "simulated data structure programming", which is,
sadly, the dominant style one sees in OOP books these days.
I see this style in nearly every OOP textbook -- especially
those aimed at beginners, because those books generally
start with "the fundamentals" of the old style. I see it
in courses at my university, and even dribbling into my
own courses.
One of the best examples of an object-oriented system is
one most people don't think of as a system at all: the
Internet:
It has billions of completely encapsulated objects (the
computers themselves) and uses a pure messaging system of
"requests, not commands", etc.
Distributed client-server apps make good examples and
problems in courses on OO design precisely because they
separate control of the client and the server. When we
write OO software in which we control both sides of the
message, it's often too tempting to take advantage of how
we control both objects and to violate encapsulation.
These violations can be quite subtle, even when we take
into account idioms such as access methods and the Law
of Demeter. To what extent does one component depend on
how another component does its job? The larger the answer,
the more coupled the components.
Encapsulation isn't an end unto itself, of course. Nor
are other features of our implementation:
The key to safety lies in the encapsulation. The key to
scalability lies in how messaging is actually done (e.g.,
maybe it is better to only receive messages via "postings
of needs"). The key to abstraction and compactness lies
in a felicitous combination of design and mathematics.
I'd love to hear Kay elaborate on this "felicitous
combination of design and mathematics"... I'm not sure
just what he means!
As an old AI guy, I am happy to see Kay make reference to
the
Actor model
proposed by
Carl Hewitt
back in the 1970s. Hewitt's ideas drew some of their
motivation from the earliest Smalltalk and gave rise
not only to Hewitt's later work on concurrent programming
but also Scheme. Kay even says that many of Hewitt's
ideas "were more in the spirit of OOP than the subsequent
Smalltalks."
Another old AI idea that came to my mind as I read the
article was
blackboard architecture.
Kay doesn't mention blackboards explicitly but does talk
about how messaging might better be if instead of an
object sent messages to specific targets they might
"post their needs". In a blackboard system, objects
capable of satisfying needs monitor the blackboard and
offer to respond to a request as they are able. The
blackboard metaphor
maintains some currency in the software world, especially
in the distributed computing world; it even shows up as
an architectural pattern in
Pattern-Oriented Software Architecture.
This is a rich metaphor with much room for exploration
as a mechanism for OOP.
Finally, as a CS educator, I could help but notice Kay
repeating a common theme of his from the last decade,
if not longer:
The key to resolving many of these issues lies in carrying
out education in computing in a vastly different way than
is done today.
That is a tall order all its own, much harder in some ways
than carrying out software development in a vastly different
way than is done today.
-----