ACM Computing Surveys 28A(4), December 1996, http://www.acm.org/surveys/1996/BlackAP/. Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below.
Abstract: This position paper outlines some important future directions for object-oriented programming languages. It was prepared as input to the object-oriented programming working group of the Workshop on Strategic Directions in Computing. It highlights the influence of Distribution, User-orientation, Monads, Types and Higher-Order programming on Object-Oriented languages.Categories and Subject Descriptors: D.1.5. [Object-Oriented Programming]D.3. [Languages, Programming]; D.3.2 Object-Oriented Languages.
General Terms: Programming Langauges, Language Design
Additional Key Words and Phrases: Distribution, User-oriented design, Meta-programming, Monads, Types and Higher-Order programming
My background is a little different from that of the typical programming
language researcher: I came to objects from distributed systems. This colours
my view on what is important in object-oriented programming. Of course, I
realize that my viewpoint is not the only one, but I think that it provide a useful mirror.
I used to think that I was being controversial when I claimed that all interesting computer systems are distributed systems! But the astounding growth of the World-Wide Web has made this conventional wisdom. Briefly, the argument is that any system that is interesting has multiple users, that these multiple users use a multiplicity of computers, and that they wish to share objects with each other.
For example, in our academic department we have thirty to forty personal Macintoshes running spreadsheets. Many of these spreadsheets are linked to one another. Depending on your point of view, either this is a collection of distributed objects, or it ought to be one! A second example comes from my graduate class in object-oriented programming. I produce example code that I show to the students, and which they may perhaps wish to incorporate into their own programming assignments. We simulate the distributed environment that we need by putting Smalltalk fileouts on the world-wide web and letting each other file them back in.
What are the consequences of this distributed perspective?
As programmers and programming language designers, we too often forget that what concerns us is often quite irrelevant to the consumer of the objects that we design. Users see objects; programmers see classes. Users are concerned with interface; programmers are concerned with implementation. From the user's perspective, some of the questions that I might like to ask are:
In contrast, the programmer's questions are different:
Twenty years of thinking of object-0riented languages as prototyping (read: "toy") languages in which the programmer was the only user have reinforced this confusion. One place where observing the distinction between programmer and user is particularly useful is in thinking about inheritance. Inheritance is a "producer feature", useful to the programmer, but largely irrelevant to the User.
The base interface is the interface used by the client. The Meta interface is used by those that want to modify the object's behaviour. This terminology and the motivation for Meta are explored thoroughly in recent work on open implementation [Xerox 1994] [Kiczales1996].
Inheritance is the classic example of a Meta interface. It lets us transform a factory object into a similar, but different, factory object. In the process we can change the features of the original that don't suit us.
Meta is not better: it is just different. We should not get so caught up in the intricacies of meta that we forget that most users can be satisfied by the base.
The kind of specification needed by a user is quite different from that required by an inheritor. Classical pre- and post-condition interface specifications are quite adequate for many users. But the heir (the person who inherits) needs much more than an interface specification. the heir's specification must describe the internal recursive structure of the object.
We should not get so bound with Meta mechanisms like inheritance that we forget that objects are created for their clients, not for their programmers.
Functional Programmers have recently become excited by the use of Monads to encapsulate effects (such as state modification and I/O) in otherwise functional programs.
For a long time I sought to understand what could be done with Monads that could not be done with Objects. Then I had an insight (thanks to Phil Wadler): the power of Monads lies not in what they allow one to do, but in what they stop someone else from doing! There is nothing that can be done with Monads that cannot be done with objects. To the contrary, there are many things that cannot be done in a monadic functional program that can be done with objects. The power of monads comes from what they prevent the programmer from doing-or more precisely, what they prevent some other programmer from doing-not from what they enable!
Should we introduce similar restrictive constructs into Object-Oriented programming languages?
Much of the power of functional programming comes from the use of higher-order data structures and strong type systems. In functional parlance, higher order data structures are data structures that contain functions. The OO analog is any object that computes a result rather than finding it by traversing a data structure. But the more interesting applications come from methods that take functions as arguments and store them in an object.
Types and higher-order functions are familiar to object-oriented language
designers, but I can't think of a single typed object-oriented language that conveniently
supports higher order functions.
Smalltalk's block is a great notation for functions. [: x | x+1] is probably
more readable than λx. x+1 (particularly once the functions are
nested). It turns out to be trivial to write a Smalltalk class Graph, which represents a directed graph using an adjacency function (just like in the mathematical definition of a graph) or a class RecList that
implements circular lists. In this case the list constructor takes as argument a function from lists to lists, and creates a list that is the fixed point of that function. For example,
RecList new: [: list | ConsList new: 1
onto: (ConsList new: 2 onto: list)],RecList represents the infinite sequence 1 2 1 2 1 2 ...
Current generation Object-Oriented languages such as Java have missed the significance of higher-order programming. What is sad is that many programmers do not seem to have noticed.
The Emerald programming lanaguage [Raj 1991] is already twelve years old, but its type system (or one that is equally expressive) is not yet available in any production language. This is in spite of the fact that almost all of the errors that I make using Smalltalk are the kind that could be caught easily by a type checker. Why has this technology not been adopted? Judging by the plethora of recent work on the interaction of inheritance and typing, I suspect that it is this interaction that leads langauge designers to more restrictive type disciplines.
If this is the case, then I suggest that we making the wrong tradeoff. It is the programmer who suffers from the absence of typing, while the meta-programmer is the one who benifits from inheritance. I believe that an adequate form of inheritance can be supported in the programming environment, and resolved statically. Because distributed programs are in a constant state of evolution, the run-time type system and the type checker must still support of dynamic program evolution. However, that support can be limited to the dynamic admission of new types and objects, and need not concern itself with the paternity of those types and objects, that is, whether they were created out of "whole cloth" or by modification of some other, pre-existing type or object.
In short, inheritance is an exotic feature, tremendously powerful, but poorly understood by the majority of programmers. Clearly, it will be present in some form in future languages, but its prescence should not be allowed to damage other parts of a language that may be more important in daily use.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org.