Ob ject-Oriented Programming:
Regaining the Excitement
Andrew P. Black
Oregon Graduate Institute of Science & Technology
Portland, Oregon, USA
Abstract. This pap er is based on a sp eech delivered at the ECOOP'98
Conference Banquet. It is not a literal transcription of my talk, since no
recording was made, but has b een reconstructed ex post facto based up on
my sp eaker's notes and my memory.Ihavealsotaken the opp ortunity
to add some headings and references.
Distinguished Chairmen, Memb ers of the Conference Committee, Represen-
tatives of the sp onsoring organizations, distinguished Professors, conference par-
ticipants, and friends: Go o d evening.
It's customary to start this kind of talk with a joke, at least in part to give
the audience a chance to b ecome accustomed to my strange accent b efore I start
to sayanything interesting, but I'm going to skip that tonight b ecause I think
that wehave already heard quite enough jokes for one evening.
To set the record straight from the very rst, I should make it clear that I do
not work for IBM, nor haveIworked for IBM in the past. Although I did once
sp end a very enjoyable year at IBM's Yorktown Heights Research Lab oratory,
IBM was very clear that I didn't work for them, even though I did turn up every
day and they did pay me: I b elieve that the distinction had something to do
with so cial security tax or health insurance.
I should also p oint out, particularly for the b ene t of those of you around
the corner who cannot see me, that yes, I am wearing a tie, but no, I don't use
a mainframe. I used to use a mainframe, but one day the mainframebrokeand
all of the little b eads came o . [At this p oint the reader will have to imagine a
large broken abacus frame with b ent wires and missing b eads.]
1 Inventing the Future of Ob ject Technology
The right thing to do in a talk of this nature is to predict the future of ob ject
technology, but prediction is hard, and predicting the future is esp ecially hard!
Alan Kay once said: \The b est way to predict the future is to inventit".And
he was remarkably accurate. Let me read you a quote from over 20 years ago.
In the 1990's there will b e millions of p ersonal computers. They will
b e the size of noteb o oks of to day,have high resolution at screen re-
ective displays, weigh less than 10 p ounds, have 10 to 20 times the
computing and storage capacity of an Alto. Let's call them Dynab o oks.
The purchase price will b e ab out that of a color television set of the
era...
Though the Dynab o ok will have considerable lo cal storage and do
most computing lo cally, it will sp end a large p ercentage of its time
ho oked to various large, global information utilities which will p ermit
communication with others of ideas, data, working mo dels as wellasthe
daily chit-chat that organizations need in order to function.
This is from Alan's pap er \The Early History of Smalltalk"[5], in which
Alan quotes an internal XeroxPARC memo from around 1976. I recommend
that pap er most highly: if you nd any wisdom in my remarks this evening,
please attribute it to Alan Kay and not to me.
My goal tonightistochallenge you to put the excitementbackinto ob ject-
orientation, and to recapture some of the dynamism of those early Smalltalk
days.
Is this p ossible? Or has ob ject-orientation b ecome like structured program-
ming: the right idea, but no longer the fo cus of innovation, exactly b ecause
everyone is already doing it. For example, wedon'thave a Europ ean Conference
on Structured Programming every year.
I don't think that ob ject-orientation is yet at that p oint. There are still many
hard problems to solve: scale and encapsulation are two that I will mention brie y
tonight.
2 Programming Language Contributions Relevantto
Ob ject-orientation
The programming language researchcommunity has historically b een a great
source of innovation. I b elievethatwe should challenge ourselves to recapture
that atmosphere of innovation; to help us on our way, I will takeabrieflookat
some of the ideas that have b een \brought to market" byin uential programming
languages over the last fortyyears. I'm not claiming that the listed languages
invented the concepts in every case, but rather that these languages were among
the rst to p opularize them.
2.1 Lisp (late 1950s)
Lisp was a startling language for its time: I b elieve that Lisp is one of Alan Kay's
\almost new things". It contributed:
{ heap allo cation and garbage collection,
{ interpreted execution, and
{ conditional expressions.
2.2 Algol 60
Another \almost new thing", in contrast to the \b etter old things" of COBOL
and FORTRAN. Its contributions include:
{ a semi-formal, concise de nition,
{ grammars as a descriptivetechnique,
{ blo ck structure,
{ recursion|but not the word \recursion";
- recursion intro duced the distinction b etween program text (or \static
instance") and its execution (or \dynamic instance"). This distinction
is the kernel of the idea that b ecame Simula Ob jects [7]. Algol 60 also
intro duced
{ declarations,
{ call-by-name,
{ \own" variables,
{ the extension of the concept of expression to non-numeric values,
- Bo olean expressions, and
- \designational expressions", and
{ the idea of \Security", whichwewould probably to day call semantic in-
tegrity.
Security is the principle that a program must either b e rejected as incorrect
by compile-time or run-time checks, or its behavior must be understandable by
reasoning basedentirely on the language semantics, indep endent of the imple-
mentation [2, 7].
However, no language is p erfect. Two \non-contributions" of Algol 60 were:
{ that the non-numeric expressions that Algol 60 chose to include were lab els,
not pro cedures; and that
{ input/output was relegated to a library.
2.3 Algol W, Pascal and Simula 67
Contributions:
{ quasi-parallel execution (previously intro duced in Knuth's SOL);
{ user-de nable typ es;
{ static inheritance (Simula's pre x classes);
{ use of pre x classes to provide \language dialects"
{ Sum typ es, also known as varianttyp es, or discriminated unions;
{ the combination of data and op erations in a single language construct; and
{ the idea that binding of a value to a name requires only typ e compatibility,
not typ e identity.
Non-contributions:
{ Explicit reference variables, and
{ Pascal's sacri ce of the security of Algol 60 bythevariant record construct.
This last innovation is p erhaps one of the reasons that Tony Hoare said of Al-
gol 60: \here is a language so far ahead of its time, that it was not only an
improvement on its predecessors , but also on nearly all its successors"[2].
2.4 Algol 68
Contributions:
{ uni cation of statement and expression, that is, making the distinction b e-
tween them one of typ e, rather than one of context-free syntax;
{ the void typ e;
{ co ercion;
{ environment enquiries;
{ conceptual minimality, for example,
- the use of references to eliminate the notion of variable, and
- the use of pro cedures to eliminate call-by-name; and
{ obtaining an extensible syntax|then an imp ortant goal|by means of the
de nition of new op erators, and by that means alone.
Non-contributions:
{ 2-level grammars as a descriptive technique, and
{ once again, breaching security,thistimeby requiring that the programmer
not exp ort a stack-allo cated variable outside of its scop e, which is not some-
thing for which implementations can easily check.
2.5 CLU, Alphard, Mo dula (1974-78)
Contributions:
{ encapsulation,
{ named scop es (i.e., the mo dule concept),
{ parametric p olymorphism, and
{ F-b ounded p olymorphism (CLU's where clauses)
- but it's not clear that the CLU designers realized at the time what they
had invented.
2.6 Emerald (1984-6)
Contributions:
{ safe, static subtyping,
{ F-b ounded p olymorphism (in the interpretation of conformity in where clauses)[4]
- but we also did not yet knowthatitwould b e given this name,
{ mobile ob jects,
{ lo cation-indep endentinvo cation,
{ ob ject constructors (which I b elieve are relevant to Ole Lehrmann Madsen's
quest to integrate prototyp e and class-based programming styles),
{ separation of typ e from implementation, and
{ the \op en world" assumption
This last is the idea that new ob jects and new classes (sup erclasses as well as
sub classes) can b e added to a system at any time, so that we don't havetoshut
down and recompile the internet.
2.7 Later Developments
What has happ ened since then?
{ multi-paradigm languages (LIFE, Leda, etc.)
{ higher-order functional languages with ob ject-oriented concepts (Ob jective
CAML, Haskel with its typ e classes, etc.)
These are interesting, but not earth-shaking.
And then, of course, wehaveJava. What are Java's advances over Emerald?
The ma jor one is of course replacing word pair brackets (like do ... end)with
curly braces fg, but we should not overlo ok typ ed byte-co de and byte-co de
veri cation.
The latter means that one can obtain a class that someone else has compiled
and b e sure that it is typ e-safe. This is a real advance, although pro of-carrying
co de [6] maywell b e a more elegant and more widely applicable wayofachieving
the same e ect.
3 A Research Agenda
To summarize this historical review, I b elieve that Programming Language Re-
search has made major contributions to the state of computing to day, but that
recently the fo cus of research has moved away from pure OO towards hybrid
languages and applications. These are interesting topics, but I do not b elieve
that wehave completed the development of ob ject-orientation itself.
3.1 Ob jects Demonstrate Recursive Structure
My prescription is that we should re-examine the core of ob ject-orientation.
Going back to Smalltalk,we nd that there are twokey ideas:
{ that ob jects lo calize data structures and the code that op erates on them in
the same place; and
{ that ob jects, using the words of Alan Kay again: are arecursion on the idea
of computer itself.
Kay writes: \The basic principle of recursive designistomake the parts
have the same p ower as the whole". Rather than dividing the computer into
\lesser stu s", like data structures and pro cedures, we should divide it into
lots of little computers that communicate together. This enables us to p ostp one
representation decisions almost inde nitely (and those are the decisions that are
almost always the cause of our troubles).
This sounds like a mo del for distributed computing to me.
The World Wide Web is the largest and most successful distributed ob ject-
oriented system ever built|but what a p o or system it is! For example, where
is lo cation indep endent naming? And how do es one intro duce a new class? The
answer to the latter question is that we p ersuade the W3 consortium to call an
international meeting to get agreement on a new proto col!
I prop ose that we take a long hard lo ok at Kay's three basic laws of ob ject-
oriented programming.
1. Everything is an ob ject.
2. Ob jects communicate by sending and receiving messages (in term of ob jects).
3. Ob jects have their own memory (in terms of ob jects).
3.2 Information Hiding
Notice that there is nothing in the concept of little computers communicating
with each other and protecting their own data that sp eaks of how to make
information hiding decisions.
Recall that the rst key idea b ehind ob jects is \lo calization", not \encap-
sulation". Parnas' idea of information hiding is a strong and p owerful idea in
program structuring: implementations of abstractions should hide as muchas
p ossible ab out themselves (but no more)!
Hence, there are two parts to each information hiding decision: wemust
sp ecify not only what to hide, but also from whom. The weakness of most en-
capsulation mechanisms is that they typically give the programmer fairly go o d
control on the what,butvery little on the whom.
Java gives us three sets for whom: metho ds in this ob ject, metho ds in ob jects
that sub class from this ob ject, and the rest of the world. But this is inadequate.
I will givejusttwo examples.
{ Think ab out allowing accessor and up dater metho ds access to a slot, but
prohibiting that access to other metho ds in the same ob ject.
{ Think ab out a p ersistent system: how can programmers evolve the contents
of an ob ject in the store if they can't access its elds?
Don't b e misled into thinking that this last class of access somehowtakes
place \outside" of the system; our goal should b e to describ e the whole world
as ob jects, and to use the re ective prop erties of those ob jects to examine and
change their structure and their proto col. To put it another way: I wantobjects
to takeover the world, so I'm not prepared to start by excluding our own pro-
gramming environments from the set of things that I can describ e with ob jects.
To the contrary: we should b e using the re ective prop erties of ob jects to build
our environments.
Rather than the \all or nothing" encapsulation paradigm, what we need is
a concept of encapsulation that is much closer to what op erating system work-
ers have thought of as \protection mechanisms". For example, one programmer
might take on several di erent roles in relation to the same ob ject: she maybe
a maintenance programmer, then a user, and mayb e later an administrator, and
under those roles, the ob jects \in the programmer's hand" should have di erent
access rights to various parts of the target ob ject.
3.3 Ob jects as an IntegrativeParadigm
The third research direction that I would like to prop ose is that of ob jects as
an integrative paradigm. The OO mo del is strong enough to capture functional
and pro cedural styles of programming, but doing this naively is likely to result
in \write only programs".
Let me explain. Many \idioms" can b e written and not read. For example, I
have used the functional style to build a Smalltalk Interval class in whichthestep
and the limit slots hold blo cks that are the step function and the limit predicate.
Smalltalk programmers will b e taken by surprise bysuchcode.
The reverse is also true: I can build ob jects in ML, but ML programmers will
not b e able to read the resulting co de.
Consequently, I do b elievethatmulti-paradigm languages have a place, but
I also b elieve that the non-OO features should b e mapp ed onto ob jects. For
example, functions should b e ob jects with the convention that they have exactly
one op eration called (meaning \apply").
Nevertheless, it is imp ortant that the new features should b e given an appro-
priate and readable syntax. The approach that I am advo cating should enable us
to retain semantic simplicity and avoid unpleasantinteractions b etween features.
During Tuesday's Panel session, one of the questioners stated that his \old
professor" (I do hate that phrase, now that I am one) said that:
Programming language p eople think that they can solveaproblemby
designing a language to express it.
I b elieve that this professor was right, and that such \language p eople" are
also right! The reason is that language shapes thought: rst we shap e the to ol,
and then the to ol shap es us.
So it is vital that the to ol b e well-made. Category theory in mathematics is
a go o d example: by exp osing similarities b etween di erentbranches of mathe-
matics, some pro ofs that were obscure and dicult b ecome self-evident. Lazy
functional languages bring some of that clarity to programming certain kinds of
problems.
Do es clarity come from having to force your problem into the mold of the
language? Only if it works! Sometimes, the struggle to force your problem into
a notation that do es not seem appropriate can yield great insight; sometimes it
is a waste of time.
3.4 Scale
The nal challenge is scaling, but wemust ask: in what dimension? The answer
is:
{ in space, that is, wide area distribution;
{ in time, that is, Persistent Ob ject Systems;
{ and, of course, in their combination.
Scaling in Space. Systems like Emerald that successfully handle distribution
in the small do so by seeking to hide the distinction b etween lo cal and remote ob-
jects. But the failure mo des of lo cal and remote ob jects are inherently di erent,
and p erformance is radically reduced by distribution. This means that ob ject
placement is absolutely critical to application p erformance|and the to ols that
are currently available to automate or even understand placement are minimal.
Another problem is how to replicate an ob ject and still preserve its \ob ject
nature".
The systems communityhasspent20years working on replication, and we
nowknowhow to implement reliable and resilient systems from replicated com-
municating ob jects. But once wehave done so, how can we treat the resulting
subsystem as a single ob ject, in order to hide its internal structure from its
clients?
A student (Mark Immel) and I presented one solution to this problem at
ECOOP'93 [1], but I can't b elieve that it is the only solution, or even that it is
necessarily a very go o d one. I encourage you to work on this problem.
Scaling in Time. I will defer to the exp erts who will b e giving tomorrow
morning's invited lecture on Persistence in Java|Malcolm Atkinson and Mick
Jordan|by mentioning only brie y some of the issues that must b e resolved:
{ compilation distributed in time;
{ explicit supp ort for versioning;
{ safe and unsafe evolution of typ es;
{ new interfaces for old ob jects; and
{ new ob jects for old interfaces.
4 Summary
The Programming Language Research communityhascontributed massively to
our progress in ob ject-orientation to date. But recently, the pace of innovation
seems to have slowed: we are making b etter old things, but I don't see the almost
new things.
My message is the following.
{ Go back to the ro ots of ob ject-orientation:
- build little computational engines that communicate with one another
to mimic the real world that we seek to mo del.
{ Use ob jects as an integrative paradigm:
- build a semantic mo del that will serve for concurrent, functional, ob ject-
oriented and, if p ossible, constraint-based and logic programming; but
- rememb er that the purp ose of a program is to b e read; and
- that idioms reduce readability whereas well-designed language constructs
enhance it.
{ Deal with the hard problems: scale, p ersistence, and their cross-pro duct.
{ Take encapsulation seriously, p erhaps learning from the OS community.
But I have to caution you to b e careful of what you learn from the Op erating
Systems Community.
Attoday's conference, I am reminded of the 1983 ACM Symp osium on Op-
erating Systems Principles, which to ok place at the Mt. Washington Hotel at
Bretton Wo o ds in New Hampshire. This is the same hotel that was the site of
the famous Bretton Wo o ds monetary conference, whichwas held there toward
the close of the Second World War. Although the plumbing hadn't b een touched
since, it was a wonderfully atmospheric old hotel. I should add that it has since
b een completely renovated.
Iwas young Assistant Professor, presenting my rst pap er at a conference,
and was somewhat overawed by all of the \grand old men" of op erating systems;
the conference has b een called the Symp osium for OS Principals, and that is
only partially a joke.
Iremember two things ab out the conference. The rst is that it marked one
of the early replicated failures of a replicated resilient system.
The Grap evine nameservice had recently b een built at XeroxPARC, and was
the sub ject of a pap er [9, 8] to b e presented at the conference that celebrated
how, by supp orting multiple servers that exchanged up dates b etween them, the
service had proved resilient to failure of one or even several of the individual
servers.
Unfortunately, all of the servers ran the same co de on the same hardware,
so when a particular packet was sent to the rst server, triggered a bug, and
caused the server to crash, the client resp onded by re-sending the same packet
to the second server, and crashing that, and so on up the replication chain. As I
recall, this packet was sent just at the time that all of the principals who might
have diagnosed the problem had left PaloAltototravel to Bretton Wo o ds.
The second thing that I recall ab out this conference is that it had shared
\resources" in the form of bathro oms b etween adjacent pairs of ro oms. It also
had multiple pro cessors, in the form of the o ccupants of the two ro oms. Thus,
to avoid collision, b oth pro cessors had to correctly execute the bathro om do or
lo cking proto col.
At breakfast on the rst morning of the conference, many of these notable
OS wizards were missing. It turned out that they had deadlo cked contending for
the bathro oms and the hotel sta had to b e called to execute a manual reset.
Thank you for listening so patiently; I hop e that you enjoy the rest of your
evening and the remainder of the conference.
References
1. Andrew P.Black and Mark P. Immel. Encapsulating plurality.InProceedings of
European ConferenceonObject-OrientedProgramming,volume 707 of Lecture Notes
in Computer Science, pages 57{79. Springer-Verlag, July 1993.
2. Charles Antony Richard Hoare. Hints on programming language design. Invited
address at ACM SIGACT/SIGPLAN Symp osium on Principles of Programming
languages, (Reprinted in Horowitz [3], pages 35{40), Octob er 1973.
3. Ellis Horowitz, editor. Programming Languages: A Grand Tour. Computer Science
Press, third edition, 1987.
4. Norman Hutchinson. Emerald: An Object-OrientedLanguage for DistributedPro-
gramming. PhD thesis, UniversityofWashington, Department of Computer Science,
January 1987.
5. Alan C. Kay. The early history of Smalltalk. In Preprints of the Second ACM
SIGPLAN History of Programming Languages Conference (HOPL{II), pages 69{
98, Cambridge, Massachusetts, March 1993. ACM SIGPLAN.
6. G. C. Necula and P. Lee. Safe, untrusted agents using pro of-carrying co de. In
G. Vigna, editor, Mobile Agents and Security,volume 1419 of Lecture Notes in
Computer Science, pages 61{91. Springer-Verlag, 1998.
7. Kristen Nygaard and Ole-Johan Dahl. The development of the SIMULA languages.
In Richard L. Wexelblat, editor, History of Programming Languages,chapter IX,
pages 439{493. Academic Press, 1981.
8. Michael D. Schro eder, Andrew D. Birell, and Roger M. Needham. Exp erience with
Grap evine: The growth of a distributed system. ACM Transactions on Computer
Systems, 2(1):3{23, February 1984.
9. Michael D. Schro eder, Andrew D.Birrell, and Roger M. Needham. Exp erience with
Grap evine: The growth of a distributed system (Summary). In Proceedings of the
Ninth ACM Symposium on Operating Systems Principles, pages 141{142. ACM SIGOPS, Octob er 1983.