The Power of Interoperability:

Why Objects Are Inevitable

Jonathan Aldrich
Carnegie Mellon University
Pittsburgh, PA, USA
[email protected]

Abstract 1. Introduction
Three years ago in this venue, Cook argued that in Object-oriented programming has been highly suc-
their essence, objects are what Reynolds called proce- cessful in practice, and has arguably become the dom-
dural data structures. His observation raises a natural inant programming paradigm for writing applications
question: if procedural data structures are the essence software in industry. This success can be documented
of objects, has this contributed to the empirical success in many ways. For example, of the top ten program-
of objects, and if so, how? ming languages at the LangPop.com index, six are pri-
This essay attempts to answer that question. After marily object-oriented, and an additional two (PHP
reviewing Cook’s definition, I propose the term ser- and Perl) have object-oriented features.1 The equiva-
vice abstractions to capture the essential nature of ob- lent numbers for the top ten languages in the TIOBE in-
jects. This terminology emphasizes, following Kay, that dex are six and three.2 SourceForge’s most popular lan-
objects are not primarily about representing and ma- guages are Java and C++;3 GitHub’s are JavaScript and
nipulating data, but are more about providing ser- Ruby.4 Furthermore, objects’ influence is not limited
vices in support of higher-level goals. Using examples to object-oriented languages; Cook [8] argues that Mi-
taken from object-oriented frameworks, I illustrate the crosoft’s Component Object Model (COM), which has
unique design leverage that service abstractions pro- a C language interface, is “one of the most pure object-
vide: the ability to define abstractions that can be ex- oriented programming models yet defined.” Academ-
tended, and whose extensions are interoperable in a ically, object-oriented programming is a primary focus
first-class way. The essay argues that the form of inter- of major conferences such as ECOOP and OOPSLA,
operable extension supported by service abstractions and its pioneers Dahl, Nygaard, and Kay were honored
is essential to modern software: many modern frame- with two Turing Awards.
works and ecosystems could not have been built with- This success raises a natural question:
out service abstractions. In this sense, the success of
objects was not a coincidence: it was an inevitable con- Why has object-oriented programming been success-
sequence of their service abstraction nature. ful in practice?
To many, the reason for objects’ success is not obvi-
Categories and Subject Descriptors D.1.5 [Program- ous. Indeed, objects have been strongly criticized; for
ming Techniques]: Object-Oriented Programming example, in an interview Stepanov explains that his
STL C++ library is not object-oriented, because he finds
Keywords Object-oriented programming; frame-
OO to be technically and philosophically unsound,
works; interoperability; service abstractions
and methodologically wrong [29]. In addition, popular
object-oriented languages are often criticized for their
Permission to make digital or hard copies of all or part of this work for flaws; for example, Hoare states that the null references
personal or classroom use is granted without fee provided that copies are not most OO languages provide were his “billion dollar
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 1 http://www.langpop.com/
of this work owned by others than the author(s) must be honored. Abstracting
with credit is permitted. To copy otherwise, or republish, to post on servers or 2 http://www.tiobe.com/index.php/content/paperinfo/
to redistribute to lists, requires prior specific permission and/or a fee. Request tpci/index.html
permissions from [email protected]. 3 http://sourceforge.net/directory/, click Advanced and
Onward! 2013, October 29–31, 2013, Indianapolis, Indiana, USA.
Copyright is held by the owner/author(s). Publication rights licensed to ACM. mouse over Programming Language, accessed 4/7/2013
ACM 978-1-4503-2472-4/13/10/13/10. . . $15.00. 4 https://github.com/languages, accessed 4/7/2013
http://dx.doi.org/10.1145/2509578.2514738
mistake”[13]. These and other criticisms have led some To support this thesis, we need a careful defini-
to argue that object-orientation became popular essen- tion of interoperable extension and an analysis of how
tially for marketing reasons: because “it was hyped objects provide it—by contrast, we’ll see that obvi-
[and] it created a new software industry.”5 ous alternatives such as abstract data types don’t (Sec-
While there has unquestionably been some hype tion 3). Alternative mechanisms can provide inter-
about objects over the years, I have too much respect operable extension only by using service abstraction
for the many brilliant developers I have met in indus- themselves—and thus are equivalent to what we con-
try to believe they have been hoodwinked, for decades sider the essence of objects.6 Interoperable extension is
now, by a fad. The question therefore arises: might essential to many modern software systems and frame-
there be genuine advantages of object-oriented pro- works, in that the core architectural requirements of
gramming that could explain its success? these systems cannot be fulfilled without it (Section 4).
Some of the advantages of object-oriented program- The rise of objects, therefore, is not a coincidence: it
ming may be psychological in nature. For example, is an inevitable response to the needs of modern soft-
Schwill argues that “the object-oriented paradigm...is ware.
consistent with the natural way of human think- Pieces of the story told here are known, more or less
ing” [28]. Such explanations may be important, but formally, within the object-oriented and programming
they are out of scope in this inquiry; I am instead in- language communities, but the larger story has not
terested in whether there might be significant technical been well told. With that story in place we can begin
advantages of object-oriented programming. to explain the success of objects on a purely technical
The most natural place to look for such technical basis.
advantages is the essential characteristics that define Along the way, we’ll connect Cook’s definition of
the object-oriented paradigm. On this question there is objects with Kay’s focus on messaging as a key to
some controversy, but I follow Cook’s definition: “an object-orientation; investigate a mystery in the design
object is a value exporting a procedural interface to of object-oriented vs. functional module systems; and
data or behavior” [8]. In other words, objects are in use the theory sketched here to make predictions both
their essence procedural data structures in the sense of about the technical feasibility of statically typed, fully-
Reynolds [27]. Cook’s definition essentially identifies parametric modules in object-oriented systems, and
dynamic dispatch as the most important characteris- about the effect of adding first-class modules to lan-
tic of objects. Each object is self-knowing (autognostic guages that do not support objects.
in Cook’s terms), carrying its own behavior with it, I hope that the arguments in this essay will inspire
but assuming nothing about other objects beyond their researchers to gather data and build systems that can
own procedural interfaces. This autognosis property, properly validate the propositions described here.
in turn, enables different implementations of an object-
oriented interface to interoperate in ways that are diffi- 2. The Nature of Objects
cult when using alternative constructs such as abstract A clear understanding of the nature of objects is essen-
data types. tial to my argument. Cook’s definition was intended
Could data structure interoperability really be so to distinguish objects from ADTs, with which objects
important? It is an excellent question, but too narrow. are often confused. However, his definition extends be-
As we will see, to understand the value of objects we yond data abstraction, following Alan Kay’s emphasis
must consider service abstractions that go beyond data on objects providing services that support high-level
structures, because it is for abstractions of components behavioral goals. As we will see, it is in its ability to ab-
and services that interoperability becomes critical. This stract behavior that object-oriented programming pro-
leads to the following thesis: vides its greatest benefits.

Object-oriented programming is successful in part 2.1 Objects and ADTs

because its key technical characteristic—dynamic Once again, Cook’s definition states that “an object
dispatch—is essential to supporting independent, in- is a value exporting a procedural interface to data or
teroperating extensions; and because interoperable ex- behavior” [8]. His essay uses a simple set example to
tension is in turn essential to the reuse of architectural illustrate the distinction between objects and abstract
code (as in frameworks), and more broadly to the de- 6 As we will see, “simulated objects” do appear in practice in systems
sign of modern software ecosystems. that require interoperable extension, but are not written in object-
oriented languages. These examples supports my thesis, which is
about object-oriented programming in the most general sense. Of
5 Joe Armstrong, quoted at http://harmful.cat-v.org/ course, when programming with objects in practice, programming
software/OO_programming/why_oo_sucks language support is convenient.
data types (ADTs). For example, an object-oriented set ADTs can also be defined in Java using classes as
type may be abstractly defined as follows: follows:
type IntSet = { final class IntSetA {
bool contains(int element); bool contains(int element) { ... }
bool isSubsetOf(IntSet otherSet); bool isSubsetOf(IntSetA other) { ... }
} }

Note that different IntSet implementations can in- As with the abstract SetModule1.IntSet de-
teroperate. For example, as shown in the code below, scribed earlier, all instances of IntSetA are instances
we can have instances of two different implementa- of the same class and have the same internal represen-
tions of type IntSet and test if one contains all el- tation.8
ements of the other. An object-oriented set type can The disadvantage of ADTs, relative to objects, is the
be described using an interface in Java; an example lack of interoperability. Consider what happens if we
is java.util.Set, or simply the interface above re- define a second Java class, called IntSetB, analogous
placing the keyword type with interface. Different to the first one above:
classes can then implement that interface. Each set ob- // different code but the same interface
ject carries its hidden implementation type with it. In final class IntSetB {
type theory, we say that objects have existential types; bool contains(int element) { ... }
the existential is opened on every access to each object. bool isSubsetOf(IntSetB other) { ... }
class IntSet1 implements IntSet { ... } }
class IntSet2 implements IntSet { ... } // in main()
IntSetA sA = new IntSetA(...);
// in main() IntSetB sB = new IntSetB(...);
IntSet s1 = new IntSet1(...); boolean x = sA.isSubsetOf(sB); // ERROR!
IntSet s2 = new IntSet2(...); Now if we create an instance of IntSetA and
boolean x = s1.isSubsetOf(s2); an instance of IntSetB, we cannot invoke the
In contrast a set ADT might be abstractly defined as isSubsetOf operation to compare their contents. The
follows: reason is that IntSetA and IntSetB are different ab-
stract types; neither is a subtype of the other. This is,
module SetModule1 { in fact, an inevitable consequence of the fact that bi-
// implementation...
nary operations on abstract data types can depend on
} with signature {
type IntSet;
the internal representation of the second object passed
in. This dependence has performance advantages, but
bool contains(IntSet set, int element); makes interoperation impossible, since IntSetB may
bool isSubsetOf(IntSet s1, IntSet s2);
ple dispatch, in which the implementation of an operation is chosen
}
dynamically according to the class of all arguments to a generic func-
Set ADTs matching this identical signature can be tion [3]. Other solutions include using double-dispatching idioms or
more ad-hoc instanceof-style class tests. A full discussion of these
implemented by multiple modules (SetModule1, solutions, including the significant modularity issues involved, is
SetModule2, etc.), but each module SetModuleN out of scope here.
defines a separate type SetModuleN .IntSet. 8 Note that the Java implementation of IntSetA uses a final class

The ADT type SetModule1.IntSet denotes the in order to sidestep the use of inheritance. Cook argues that inheri-
tance, while valuable, is a secondary and optional feature of objects.
fixed but hidden representation defined in module
The design of the Self language illustrates this point, providing code
SetModule1. All instances of SetModule1.IntSet reuse via delegation instead of inheritance [32]. Others agree that
have the same representation, and both Cook and inheritance is secondary to dynamic dispatch. For example, when
Reynolds point out that this has some advantages: the Kay discusses the six main ideas of Smalltalk, inheritance is not men-
tioned, but dynamic dispatch is (in the form of messaging) [18]. Like-
isSubsetOf operation can be defined in terms of the wise, Gamma et al. argue that a central principle of object-oriented
hidden representation, which can be asymptotically design is to “favor object composition over class inheritance,”[11]—
more efficient than implementing isSubsetOf in and note that composition typically leverages dynamic dispatch in
terms of contains, as must be done in a pure object- the setting of patterns. When discussing framework design, John-
son and Foote distinguish white-box frameworks based on inheri-
oriented implementation of the IntSet interface. This tance from black-box frameworks based only on dynamic dispatch,
efficiency difference can be critical in practice.7 and argue that “black-box relationships are an ideal towards which
a system should evolve” [16]. While acknowledging that inheritance
7 In practical object-oriented settings, the efficiency of binary opera- is a feature of many OO languages and may have significant value
tions can often be regained, aside from any cost associated with dis- in many designs, I will not consider it further, so as to focus on the
patching itself. This is done most elegantly through the use of multi- most important, and most unique, feature of objects.
very well have an internal representation that is incom- What I got from Simula was that you could now
patible with that of IntSetA. replace bindings and assignment with goals. The
Because each module hides the representation of the last thing you wanted any programmer to do is
ADT it defines, ADTs are also existential types. How- mess with internal state even if presented figu-
ever, these existential types are opened once, when the ratively. Instead, the objects should be presented
defining module is imported into the program, rather as sites of higher level behaviors more appropriate for
than on every invocation of an operation. Thus the dis- use as dynamic components. [18]
tinction between objects and ADTs can be thought of in
type theory as the difference between closed and open
Thus, while comparing objects to ADTs may be use-
existentials.
ful for making intellectual distinctions, Kay suggests
Discussion. Cook’s essay focuses on the technical and that the power of objects is not in representing data
theoretical differences between objects and ADTs. He structures, but in representing higher-level goals. The
highlights the tradeoff between the interoperability idea of goals suggests an analogy to planning in ar-
provided by objects and the shared representation pro- tificial intelligence: rather than express an algorithm
vided by ADTs. But due to the focus of his essay, the with even high-level state and assignment, it is bet-
larger consequences of the interoperability provided ter to express declarative goals and declarative rules
by objects are only briefly discussed. At this point a for achieving them, and rely on a search engine to
reader may be forgiven for asking, what is the big deal apply the rules in a way that accomplishes the goal.
about interoperation? After all, Cook quotes Liskov Object-oriented programming is not fully declarative,
making the following cogent argument: but Kay’s point is that the abstraction provided by a
method-based interface enables a lot of client code to
Although a program development support approach the declarative ideal.
system must store many implementations of When discussing his view of objects in Smalltalk,
a type..., allowing multiple implementations Kay writes of the “objects as server metaphor” in
within a single program seems less impor- which every “object would be a server offering ser-
tant. [22] vices” that are accessed via messages9 to the object [18].
Perhaps Liskov is right. Does it really matter In fact, Kay considers objects the “lesser idea” and
whether we have two different implementations of Set states that “the big idea is messaging.”10 On a techni-
in a program? Why don’t we just pick one that is effi- cal level, in Smalltalk messages are “a procedural in-
cient and has the features needed for the program? terface to data or behavior,” which is consistent with
As far as data abstraction goes, this defense of ADTs Cook’s definition, but again Kay de-emphasizes data
may be correct. To investigate why having multiple abstraction in favor of behavior and high-level goals.
implementations of an abstraction might be important This focus on goals also suggests that whereas ADTs
indeed, we must broaden our view and look beyond are focused on lower-level data representation and ma-
data abstraction. nipulation concerns, objects are focused more on ab-
stractions that are useful in high-level program orga-
2.2 Beyond Data Abstraction: Behavior, Messages, nization. Thus, in looking for the advantages of ob-
and Services jects, perhaps we ought not to focus on data abstrac-
Cook’s essay focuses primarily on data abstraction, be- tions for our examples. Instead of Reynolds’s proce-
cause he is comparing objects to ADTs and data ab- dural data structures, in the remainder of this essay I
straction is what abstract data types are intended to will generally use the term service abstractions, reflect-
do. However, his definition of objects is more gen- ing Kay’s view of objects as servers that provide ser-
eral: “...a value exporting a procedural interface to data vices to their clients. A service abstraction is, on a tech-
or behavior.” This reflects a broader view of object- nical level, the same form of abstraction as a procedu-
orientation, one that can be seen even more clearly in ral data structure, but it may be used to abstract any
OO’s origins in Simula and Smalltalk. Dahl and Ny- set of services, not just data structure manipulations.
gaard, for example, related object-oriented program- We could also simply use the term object, following
ming to simulation, saying that “a program execution Cook’s definition, but the term service abstraction will
is regarded as a physical model, simulating the behav-
ior of either a real or imaginary part of the world” [21]. 9 Note that messages in Smalltalk are synchronous method calls; they
While this quote focuses more on the purpose of OO
are not asynchronous or distributed in the sense of network mes-
rather than its mechanisms, a simulation nevertheless sages, although Kay derives substantial inspiration from network-
focuses on behavior more than data. Alan Kay under- based metaphors.
scores this point: 10 Alan Kay, email sent October 10, 1998, to [email protected]
remind us that we are focused specifically on the dy- intuition from the widget example that this might
namic dispatch feature of objects.11 take on increased importance in service abstractions,
Taking Smalltalk’s pioneering work in GUI libraries I now propose a candidate for the leverage provided
as an inspiration, we will explore the generalization to by object-oriented service abstractions in design:
service abstractions through the example of a widget:
The key design leverage provided by objects is the abil-
interface Widget { ity to define nontrivial abstractions that are modu-
Dimension getSize(); larly extensible, where instances of those extensions
Dimension getPreferredSize();
can interoperate in a first-class way.
void setSize(Dimension size);
void paint(Display display); Let me define the these terms with more care:
}
• Nontrivial abstraction. An interface that provides
While a widget certainly has data—its size, and
at least two essential services.
perhaps widget-specific data related to what the wid-
get is displaying—abstracting that data is not the pri- • Modular Extensibility. New implementations not
mary purpose of a widget. Rather, a widget’s pur- anticipated when the abstraction was designed can
pose is to abstract the behavior of a user interface el- be provided without changing the original abstrac-
ement. In the simple interface above, inspired by the tion.
ConstrainedVisual interface from Apache’s Pivot • First-class Interoperability. Clients can instantiate a
UI framework,12 the service abstraction captures the number of different implementations of an abstrac-
negotiation between a UI element and its container tion and manipulate those instances together in a
concerning how large the UI element should be, as well first-class way. First-class interoperability has three
as the goal of painting itself on a display device. facets:
More importantly, the interoperability advantages
of object-oriented service abstractions over ADTs Direct interoperation. If the abstraction defines
suddenly become more obvious with this example. a binary operation, the arguments to that oper-
While a framework such as Apache Pivot provides ation need not be instances of the same imple-
many widgets, the space of possible widgets is much mentation. This form of interoperation is analo-
larger, and so programmers using the framework will gous to gears that mesh; mathematically, it corre-
likely want to define their own, or even use wid- sponds to a fold operation.
gets developed by strangers.13 GUI frameworks pro- Uniform treatment. Clients can uniformly in-
vide facilities to recursively and dynamically com- voke operations on instances of different im-
pose atomic widgets into composite widgets, and ul- plementations, without distinguishing the par-
timately into a complete user interface. For example, a ticular implementations involved (e.g. by using
CompositeWidget might be defined as: a static type or an explicit typecase operation).
interface CompositeWidget extends Widget { This form of interoperation is analogous to balls
void addWidget(Widget chld, Position p); within a ball bearing, which may not touch each
} other directly but nevertheless must match each
other closely; mathematically, it corresponds to a
Here addWidget is a binary operation: Compos-
map operation.
iteWidget is a kind of Widget, and it must interoperate
with other kinds of widgets that are added to it. It is First-class manipulation. Instances of different
essential, in particular, that custom widgets written by implementations can be manipulated together as
programmers can take their place in a user interface to- first-class values. For example, it should be pos-
gether with widgets from the base framework, as well sible to store a collection of instances of differ-
as widgets written by strangers. ent implementations in a single data structure in-
stance, then dynamically select element(s) from
3. The Design Leverage of Objects the collection and invoke operations on them.
Based on Cook’s insight that different object-oriented
implementations of a set can interoperate, and the Discussion. The reason to consider only nontrivial ab-
11 e.g. as stated before, I am not considering inheritance—surely the
stractions is that if an abstraction has only one service,
one can use a function to abstract it. Functions are com-
question of whether inheritance contributes to the success of objects
is interesting, but it is out of scope for our current purposes. pletely ideal in such cases—but some abstractions that
12 http://pivot.apache.org/ at first appear to be simple turn out to be richer than ex-
13 we will see an example of this later when looking at the Microsoft pected in practice. Consider the Widget example: the
Office plugin ecosystem. most important function in the interface is probably
paint, and a trivial academic example might include above, the C++ compiler must know the precise im-
only that, leading to the mistaken impression that just plementation class of each iterator so that it can sup-
passing a first-class function around suffices to encap- port template code generation. This is a reasonable as-
sulate the widget abstraction. In reality, widgets must sumption in the typical modes of use of generic pro-
manage other concerns, such as their size, which re- gramming, but it is nevertheless a serious limitation
quires communication with both their container and in many other cases. For example, if we store differ-
their children. I have in fact already oversimplified: the ent kinds of iterators in a list, typical type systems lose
true interface on which the Widget example is based track of the particular implementation class of each it-
has nine methods, and adds the additional concern of erator, and so we cannot use pure generic program-
revealing the widget’s baseline.14 ming to invoke copy operations on them; we must fall
The definition of modular extension captures back on dynamic dispatch to make copies.
Meyer’s open-closed principle [24], which states that ab- Objects, on the other hand, are first-class values; we
stractions “should be open for extension, but closed can see this in Cook’s definition, which starts “objects
for modification.” It is particularly important when an are values....” We therefore characterize object-oriented
abstraction is designed by one organization, but ex- service abstractions as providing a first-class notion of
tended in an unanticipated15 way by another; in this interoperability. With service abstractions, one can use
case, the second organization may not be able to mod- multiple implementations of an abstraction together,
ify the original abstraction.16 even when instances of the abstractions are handled in
Reynolds originally suggested interoperability as a a first-class way.
benefit of procedural data structures [27], and Cook To illustrate first-class interoperation, consider a
points out that as a consequence, when using a pure scenario in which we build a composite widget that
object model, binary operations should work on differ- allows the user to select one of several visualizations,
ent implementations. This direct interoperability prop- which are swapped when the user clicks a button.
erty is critical in the Widget example, where the Here the choice of a visualization widget to go in-
CompositeWidget must be able to integrate widgets side the CompositeWidget is made dynamically, yet
defined by strangers. the composite widget interoperates with the visualiza-
It turns out that simple forms of interoperability tion widget in the sense that the latter is passed to the
can be supported through mechanisms other than ob- addChild method of the former.
jects, however. A notable example is generic program- I use the term first-class interoperation broadly, to
ming [25] as represented in the C++ Standard Template include not just invoking binary methods, but also the
Library (STL). For example, iterators in the STL can be general ability to operate uniformly on instances of
used to copy elements from one collection to another. multiple different implementations. For example, the
The copy operation is binary, accepting a source and CompositeWidget must store its child widgets to-
a destination iterator. Although iterators are C++ ob- gether in some kind of data structure. When the paint
jects, dynamic dispatch is not used to enable interop- method of CompositeWidget is invoked, it must iter-
eration of different iterator implementations. Instead, ate over the child widgets and invoke paint in turn
they are defined using C++ templates, which essen- on each one of them. Note that the implementation
tially generate a fresh version of the copy operation for of CompositeWidget.paint() must not rely on an
every pair of source and destination iterator types. explicit typecase to determine the implementation of
A key limitation of the interoperability provided by each child widget before invoking paint on the child;
generic programming mechanisms is that it is second- a typecase would enable the container to work with a
class, precluding the manipulation of iterators as truly fixed set of widget implementations, but in that case
first-class values. For instance, in the iterator example the unmodified container code could not work with
new widget implementations.
14 see http://pivot.apache.org/2.0.3/docs/api/org/
apache/pivot/wtk/ConstrainedVisual.html Alternatives to objects. Are there technical ap-
15 By unanticipated extension I mean an extension for which neither
proaches, besides the service abstraction technique
the extension’s code, nor the particular feature(s) being added by the used in objects, that can provide the design benefits de-
extension, were explicitly anticipated by the designer of the abstrac-
tion being extended. Of course, in order to design an extension point scribed above?
at all, the designer must have some idea of the class of features the I have already established that abstract data types
extension point is intended to support, but it is typically impractical do not provide the required interoperability for bi-
to enumerate all features that fall into that class. nary methods. In fact, even in the absence of binary
16 Such modifications may be literally impossible if the abstraction
methods, they fail the first-class interoperability test:
is distributed in binary form; or they may merely be infeasible in
practice because the second organization wishes to avoid modifying a data structure may be a list of IntSet1 or a list of
(and then maintaining) a component it did not develop IntSet2, but we cannot define a list that mixes in-
stances of the two types.17 ADTs are therefore not a As an example of such a technique, consider the fol-
solution.18 lowing Standard ML implementation of a Set service
A module is a similar kind of abstraction to an ob- abstraction:20
ject: both typically present a procedural interface to datatype IntSet = IntSet of {
the outside world, both encapsulate state, and both are contains : int -> bool,
typically given types (or module signatures) that per- isSubsetOf : IntSet -> bool
mit subtyping. To attain the expressiveness of objects, }
however, modules must be made first class, a property
rarely found in widely-used languages, but which is an fun makeSingletonSet(x:int) = IntSet {
ongoing topic of research [5]. I would consider a first- contains = fn(y:int) => (y = x),
class module system, such as that provided in recent isSubsetOf =
versions of OCaml, to provide service abstractions.19 fn(s:IntSet) =>
let
Haskell’s type classes [34] cannot directly express
val (IntSet srec) = s
service abstractions, but rather are similar to generic
val scontains = #contains(srec)
programming in their support for interoperation. The in
natural signature of a binary operation in a Haskell scontains(x)
type class requires both arguments to have the same end
type; thus, binary operations typed in this way can- }
not operate on two different implementations of a type
Here the IntSet object interface is defined as an
class. More fundamentally, different implementations
ML datatype consisting of a record with two fields.
of a type class cannot be manipulated together in a
Each field stores a function that implements a method:
first-class way, for example by putting them in the
same list. Achieving direct interoperability with type the contains field, for example, holds a function
that takes an int parameter and returns a bool re-
classes is possible, but requires more complexity in the
sult. The makeSingletonSet function creates a sin-
definition of the type class, so that binary operations
take two type arguments as well as two value argu- gleton set holding the single value x, passed as an ar-
gument to this “constructor.” The constructor returns
ments. In order to regain first-class manipulation—for
an instance of the IntSet datatype, with the “meth-
example to put different instances of different imple-
mentations of a type class into the same list—each in- ods” implemented appropriately to match the behav-
ior of a singleton set. contains simply holds a func-
stance must be wrapped in a datatype, creating an ex-
istential that stores the type class of each instance. The tion (introduced with the fn keyword) that compares
the method argument y to the single set element x.
use of such an encoding is inconvenient, but I would
isSubsetOf is slightly more complex. We must un-
consider it a use of service abstractions.
pack the IntSet datatype s to get at the record srec
Object encodings. Various techniques have been pro- inside. Then we can select the contains method us-
posed for encoding objects using functions [7, 19]. ing ML’s record selection operator, #. Finally, we can
Not just topics of theoretical study, these techniques implement isSubsetOf by checking if the other set
have been used to construct frameworks in an object- contains the singleton element x.
oriented style within non-OO languages. For example, The code above is more verbose than necessary in
the GTK+ framework is an object-oriented toolkit for order to make it more accessible to those not famil-
creating graphical user interfaces that is implemented iar with Standard ML. Using the pattern matching,
in C. I consider a use of these techniques to be uses of type inference, and currying facilities of Standard ML,
service abstractions. one can define makeSingletonSet much more suc-
cinctly as follows:
17 A language with union types could support heterogeneous lists,
fun makeSingletonSet x = IntSet {
but then we cannot use the sets when we get them out of the list contains = fn y => y = x,
without using a typecase operation isSubsetOf = fn IntSet S =>
18 Please note that I am not arguing against ADTs. There are good
#contains S x
reasons to support ADTs well in programming languages—for ex-
}
ample, the increased efficiency that ADTs provide when implement-
ing binary methods. I am only arguing that ADTs do not solve the Is this solution—or similar encodings [19] in
particular interoperability problem that service abstractions solve.
We will see, from a discussion of frameworks and ecosystems, that other languages—an adequate replacement for ob-
this problem is important in practice. jects? Clearly it is a service abstraction, and therefore
19 Some module import constructs could even be viewed as a simple realizes all the benefits that objects obtain from their
kind of inheritance—but as usual a detailed examination of this is
out of scope. 20 Thanks to Adam Chlipala for suggesting this encoding style.
service abstraction nature. On the other hand, ML does seminal paper on the criteria to be used in decompos-
not provide direct language support for service ab- ing systems into modules [26]. Parnas’s argument has
stractions, e.g. via class and method constructs; this become a pillar of software design: nearly all software
is instead an encoding, and that involves tradeoffs. In must change over time, so a software system should be
the example above, the drawbacks include some ver- decomposed in a way that hides (i.e. isolates) decisions
bosity and awkwardness, caused by the need to wrap that are likely to change. The implication is that when
and unwrap the IntSet datatype to get at the record change comes, it can be accommodated by providing
inside, and the encoding of methods by binding first- a new implementation of the abstraction captured by
class functions to fields. There are potential advantages the module’s interface.
too—for example, we can avoid some type annotations So extension is important for facilitating software
due to the type inference provided by Standard ML. evolution. However, is the interoperability of exten-
For programs that have only incidental need of ser- sions necessary in practice, beyond examples such as
vice abstractions, such encodings may be adequate or widgets?
even desirable. On the other hand, it is my anecdo-
tal observation that few object-oriented programmers 4.1 Software Frameworks
find such encodings acceptable. While the GObject en- To consider whether interoperation between extensions
coding used by GTK does have a significant user base, is commonly needed, let us turn our attention next to
it is painfully verbose—to the extent that the Vala21 software frameworks. A software framework is “the
language and the GObject Builder preprocessor22 were skeleton of an application that can be customized by
developed to allow GTK/GObject developers to write an application developer” [15]. This customization oc-
higher-level object-oriented code, which is then trans- curs when the developer “supplies it [the framework]
lated into C code compatible with GObject. This sug- with a set of components that provide the application
gests that direct language support for service abstrac- specific behavior” [16]. These components are imple-
tions is almost a requirement for programs that are ex- mentations of “abstract designs” defined by the frame-
pected to benefit significantly from their use. Let us work; thus frameworks inherently require extensible
now therefore look at what kind of software requires abstractions.
a significant use of service abstractions, and whether How do frameworks differ from more well-known
that class of software is important. approaches to reuse, such as libraries? While libraries
typically provide reusable primatives such as func-
4. The Importance of Interoperability tions and data structures, frameworks provide archi-
So far I have argued that objects provide a form of tectural reuse [10, 14, 15]: reuse of the overall design
extension in which extensions are interoperable, and of an application, along with code that realizes that de-
that this form of extension can be achieved in other sign. This reused code may include architecturally im-
technologies only with service abstractions that closely portant abstractions (typically interfaces), default im-
simulate the essence of objects. Does this matter? plementations of those abstractions, and glue code that
To answer this question, let us return to the idea that ties the abstractions together and allows them to com-
objects are focused on abstractions for high-level pro- municate. The architectural reuse provided by frame-
gram organization. This suggests that we study how works is inherently higher-order in nature, because the
extensibility and interoperability are used in high-level framework code invokes extensions provided by the
software design. We will first review the theory ex- application.23
plaining how modular extensibility can facilitate soft- The importance of frameworks. Why are frameworks
ware change. Second, we will look at how interopera- interesting to study? First, because the architectural
ble extensions are leveraged by software frameworks reuse they provide is unique and important, both in
in order to provide a higher-level form of reuse com- theory and in practice, and second, because as we will
pared to libraries. Third, we will look at how frame- see, many frameworks would not be possible without
works facilitate software ecosystems, which constitute the technical benefits provided by service abstractions.
some of the most high-value software we see today. Consider first the theoretical benefits of frameworks
Let us first consider the theory of how modular ex- in design. Frameworks support reuse at an architec-
tension facilitates software evolution. The need for a tural granularity, which is larger than classes:
software system to support new, unanticipated imple-
mentations of an abstraction was discussed in Parnas’s [Frameworks] provide a way of reusing code
21 https://wiki.gnome.org/Vala
that is resistant to more conventional reuse at-
22 http://www.jirka.org/gob.html – developed because 23 This is sometimes called the Hollywood principle: “don’t call us,

“writing a fully featured GObject is a hassle” we’ll call you” [33].

 tempts. Application independent components the functions the respective interfaces are named af-
can be reused rather easily, but reusing the edi- ter, they provide methods for configuration and tear-
fice that ties the components together is usually down.24 Every major framework of which I am aware
possible only by copying and editing it. [16] similarly defines abstractions that are similarly rich, if
not much richer.
Johnson and Foote are arguing that the reuse pro-
Extensibility. The abstractions a framework defines
vided by frameworks is different in scale from the
are designed to be extended in order to customize
reuse provided by libraries. The higher-order nature of
the framework. Meyer’s open-closed principle [24] is
frameworks allows the reuse not just of a data struc-
a cardinal rule of framework extension: the applica-
ture or a set of routines, but of infrastructure that ties
tion should extend the framework without modify-
together many large-scale plugin components. Devel-
ing its code. For example, when Apache’s Pivot UI
opers use frameworks because the larger-scale reuse
framework is used, a binary JAR library stores the
they provide can reduce development times dramat-
framework code. Although the code is available in this
ically; Johnson suggests frameworks may reduce de-
open-source project, application developers would be
velopment effort by an order of magnitude [15].
ill-advised to modify it; if they did, they would find
Because of the economic benefits of larger-scale, ar-
it more difficult to incorporate framework enhance-
chitectural reuse, frameworks have become a critical
ments and bug fixes into their applications in the fu-
part of the modern application landscape. Web-based
ture. Thus, extension of framework abstractions must
software is almost invariably written on top of a web or
be modular and should not change the framework
application framework such as Rails, Django, Spring,
source code.
.NET, Servlets, or EJB. The popularity of the Ruby lan-
Furthermore, frameworks typically must support
guage, in fact, appears to derive mostly from the pop-
unanticipated extension as well. For example, when
ularity of Rails. In the mobile space, every Android ap-
one organization defines a framework, it is unrealis-
plication must build on the Android framework. The
tic to assume that organization can anticipate all the
dominant platform for Java tools is the Eclipse frame-
extensions that strangers will make, because it does
work. Virtually all graphical user interfaces are de-
not know the particular problems that the extensions
veloped using GUI frameworks such as AWT, SWT,
are intended to solve. The designers know the frame-
Swing, Qt, and GTK+. Frameworks such as Google’s
work will be extended somehow, and the abstractions
MapReduce and Apache Hadoop are ubiquitous in big
the framework provides define the kinds of extensions
data applications.
that are possible, but the designers cannot anticipate
Do frameworks need objects? Let us now consider the details of specific extension implementations.
whether frameworks can be defined without the ser-
Interoperability and uniform treatment. It is possi-
vice abstractions (e.g. as provided by objects). I first
ble to design a framework, achieving all the important
examine the definition of unique design leverage pro-
reuse benefits that frameworks typically bring, with-
vided by service abstractions described earlier: the
out requiring interoperability or uniform treatment of
ability to define nontrivial abstractions that are mod-
different implementations of the framework abstrac-
ularly extensible, where instances of those extensions
tions. Such a framework might be instantiated with
can interoperate in a first-class way. I evaluate whether
exactly one implementation for each customizable ab-
frameworks require each part of this definition, both
straction it defines. In this case, the framework could
in the abstract and with respect to the example widget
be implemented using modules or abstract data types.
framework.
The FoxNet system [2], an implementation of a net-
Abstraction. As described by Johnson and Foote, work protocol stack in Standard ML, is a concrete ex-
frameworks unquestionably define abstractions [16]: ample of this scenario. FoxNet defines a family of ab-
it is these abstractions that are extended by applica- stractions using an ML signature called PROTOCOL,
tions in order to provide application-specific behav- with subsignatures for transport protocols such as TCP
ior. While some of the abstractions defined by frame- and UDP as well as protocols from other layers of the
works may be simple observers that could be imple- network stack, including IP, DNS, ETHERNET, etc. Dif-
mented with a first-class function, many frameworks ferent modules implement these abstractions, and an
define nontrivial abstractions. In Apache’s Pivot UI application can be formed by composing the abstrac-
framework, the equivalent of the widget interface has tions together. In the FoxNet design, implementations
nine methods dealing with three separate concerns; it
is not trivial. Even the Mapper and Reducer interfaces 24 see http://developer.yahoo.com/hadoop/tutorial/
in Hadoop have three methods each—in addition to module5.html for an example of how this may be useful
of TCP and UDP can be substituted for one another at sources, respectively; and getServletInfo, which is
compile time, but it is not possible to instantiate one of useful for administration of the web server on which
each and choose between them at run time: the abstract the servlets are installed. Although the heart of the ab-
data types they define are different. Thus the uniform straction is the service method, the other concerns
treatment criterion is not met by this framework—and are quite important in practice; the abstraction is not
indeed, FoxNet did not require anything like objects trivially reducible to a single function.25
for its implementation.
Most frameworks, however, do rely critically on interface Servlet {
void service(Request req, Response res);
uniform treatment and/or interoperability. We have al-
void init(ServletConfig config);
ready seen that this is important for a UI framework
void destroy();
such as Apache’s Pivot: the user must be able to hierar- String getServletInfo();
chically compose widget instances at run time, which ServletConfig getServletConfig();
requires a composite widget to store different kinds of }
child widgets in a data structure, treating them uni-
formly. Furthermore, the operation to add a child to a The point of Servlet is to support unanticipated
composite widget is a binary method, requiring direct extensions of a web server without changing the web
interoperability. server’s code. Furthermore, the web server may have
Typically, frameworks are not like FoxNet: rather several servlets installed, which respond to requests
than being limited to a single implementation for at different URLs. These servlets must necessarily be
each abstraction, they accommodate many implemen- stored in a data structure mapping each URL to the
tation plugins for each extension point. As the frame- appropriate servlet, thus requiring uniform treatment
work typically owns the application’s thread of con- of servlet extensions. Therefore, we observe that the
trol, it must invoke operations of plugins at appropri- full functionality of the servlet framework cannot be
ate times. To do this, the framework must keep the var- realized in a system without using service abstractions.
ious plugins in some kind of data structure and, when
some event happens, determine which of the plugins LLVM. The Low-Level Virtual Machine (LLVM) is “a
to invoke. Any framework that does this is relying on compiler framework designed to support transparent,
uniform treatment of implementations, and must be lifelong program analysis and transformation for arbi-
implemented using service abstractions. trary programs” [20]. As a framework, it is designed
Similarly, many frameworks exist specifically in or- to be extended with new analysis and transformation
der to enable plugins to interact and build on one passes, and we are interested in whether this extensi-
another. This is true of UI frameworks, in which bility support requires service abstractions. LLVM in-
programmer-defined widgets can be dynamically se- cludes a FunctionPass abstraction, defined using a
lected to be composed (using the Composite pattern) C++ class whose simplified interface is shown below.
or wrapped (using the Decorator pattern [11]) by Clearly, FunctionPass is a rich abstraction, support-
framework-defined widgets. This dynamic selection ing methods not just for running an analysis or trans-
of a programmer-defined plugin to interoperate with formation pass (runOnFunction), but also a pair of
framework-defined implementations also requires in- methods for initialization and cleanup, a method for
teroperability of implementations, and must be imple- printing analysis results in a human readable form,
mented using service abstractions. and a way of specifying usage constraints such as
which other analyses this analysis depends on.
4.2 Interoperability in Particular Frameworks
class FunctionPass {
Let us now consider additional examples of frame- virtual bool runOnFunction(Function &F);
works, illustrating the degree to which they require the virtual bool doInitialization(Module &M);
unique interoperability of extensions provided by ser- virtual bool doFinalization(Module &M);
vice abstractions. virtual void print(raw_ostream &O...);
virtual void getAnalysisUsage(Usage &I);
Servlets. The Java Servlets framework supports the }
implementation of dynamic web pages. A simplified
Servlet interface is shown in the next column. The 25 Interestingly, this is
done with a single function in the Rails frame-
interface encapsulates several concerns. The most im- work. However, Rails is well-known for its “convention over config-
portant concern is responding to web requests, in the uration” philosophy, which makes it very easy to use if your appli-
cation can fit into Rails’s design—and almost impossibly awkward
service method. Other concerns include lifecycle
if your application is a poor fit. This suggests that Rails is optimizing
methods init and destroy which provide mecha- for the most common case, while the servlet framework is trying to
nisms for the servlet to initialize itself and clean up re- achieve broad coverage across many kinds of applications.
 While the LLVM provides many analyses, it is in- Discussion. These frameworks and framework-like
tended to be extended with analyses for language- systems are not anomalies. Every framework of which
specific virtual machines built on the LLVM frame- I are aware, with the exception of FoxNet, relies on
work. These extensions should not require modifica- abstractions like these. It is fair to say that without a
tion of the underlying LLVM, and must interoperate service abstraction mechanism, software frameworks
with other custom and built-in extensions. For exam- as we know them, with all of their economic impact,
ple, a PassManager class stores a list of passes and would not exist.
schedules them to run in an efficient order. Because it
stores passes in a list, PassManager can only be im- 4.3 Interoperability in Software Ecosystems
plemented if FunctionPass is a service abstraction. Interoperability is important, not only because of the
reuse provided by frameworks, but also because it sup-
Linux and other C frameworks. GTK+ has already
ports the development of software ecosystems. A soft-
been mentioned as an example of an GUI framework
ware ecosystem is a “set of software solutions that en-
that needs service abstractions for extensibility—but
able, support, and automate the activities...[of] actors
it turns out the Linux operating system can also be
in the associated social or business ecosystem...” [4].
viewed as a framework that uses service abstractions.
Examples of software ecosystems include mobile plat-
Robert Love states:
forms such as iOS and Android, operating systems
such as Windows or Linux, application suites such as
People often miss this, or even deny it, but there Microsoft Office, tool platforms such as Eclipse, and re-
are many examples of object-oriented program- tail marketplaces such as Amazon’s.
ming in the kernel. Although the kernel devel- Software ecosystems have enormous economic im-
opers may shun C++ and other explicitly object- portance because of network effects [17]: a platform
oriented languages, thinking in terms of objects such as the iPhone becomes more valuable the more
is often useful. The VFS [Virtual File System] is a people use it, and (critically for our purposes) the more
good example of how to do clean and efficient apps that are available on the platform. To consider the
OOP in C, which is a language that lacks any value of networks, consider that in 2012, the largest
OOP constructs. [23] company in the world by market capitalization was
Apple, whose success is largely attributable to its con-
trol of the iOS ecosystem; and the four next technol-
Linux uses service abstractions in order to support ogy companies were Microsoft, IBM, Samsung, and
multiple file systems. There are vtable-like structures Google, each of which is notable for its central involve-
such as file operations that are used to dispatch ment in one or more software ecosystems.26
operations such as read to the code that implements Ecosystems may or may not be based on frame-
file reading in a particular driver. Files in Linux are works in the sense that Johnson defines them, but they
a rich abstraction, supporting 13 different operations have similar requirements for extensibility and inter-
in Linux version 2.4.2, and Linux is intended to sup- operability. Bosch argues that extensibility is a criti-
port extension with new file systems. These exten- cal success factor of both operating system-centric and
sions must interoperate: directories from one file sys- application-centric software ecosystems [4]. However,
tem may have symbolic links to files in another file sys- it is also critical that independently developed exten-
tem, for example. Linux file systems also define service sions interoperate. Interoperation of independent ex-
abstractions—with dispatch tables—for the mounted tensions is enabled in software ecosystems because
file system itself (a superblock), as well as inodes and “the architecture provides a formalization of the rules
directory entries. of interoperability and hence teams can, to a large ex-
The use of objects in Linux is not limited to files— tent, operate independently” [4].
there are on the order of 100 different object struc-
tures similar to file operations [6]. More broadly, Android. The Android platform illustrates the critical
service abstractions are used not just in Linux and need for interoperability in software ecosystems. One
GTK, but also in several other C-based framework set- of the benefits of Android is that user-defined apps can
tings. For example, the GStreamer multimedia frame- substitute for system apps. For example, the Smartr
work uses the same object system as GTK+ to sup- Contacts app27 provides the same functionality as An-
port plugins for different container formats, streaming droid’s built in Contacts application, but adds features
protocols, and codecs, among others. GStreamer sup-
ports plugins written by strangers, and plugins can be 26 Source:
Financial Times Global 500 2012, available at
loaded and selected dynamically based on the media http://www.ft.com/intl/companies/ft500
type being played. 27 https://www.xobni.com/download/android
such as contact synchronization, integration with Twit- This is neither an isolated nor an unimportant ex-
ter and Facebook, and an integrated history of inter- ample. The content provider functionality is the most
actions. When another app, such as the phone dialer, important means by which applications in Android
needs contact information, the user is asked which share data; it is critical to the economic network effect
contact manager to use, and the Smartr Contacts app where the availability of one app on Android makes
can be dynamically chosen. The ability to replace de- another app more valuable. Nor is the use of service
fault apps with customized ones is notably used to de- abstractions incidental. I am not merely observing that
velop skins such as the recently announced Facebook Android uses objects for this abstraction; I am argu-
Home,28 which overrides many default elements of the ing that any Android-like framework that provides support
Android platform with Facebook-enhanced function- for content providers must do so via service abstractions.
ality. That is because the framework must accept multiple
Android is an interesting case because on the An- implementations of the content provider from the ap-
droid platform different apps execute in different vir- plication, and it must store these implementations uni-
tual machine processes, so they are not directly using formly in a data structure; this is possible only if con-
object-oriented method calls to communicate. How- tent providers are service abstractions.
ever, the processes nevertheless have an service-based Now, a non-OO app platform might force each app
interface, in the sense that they communicate only via to provide a single content provider implementation
messaging, and in the sense that different implemen- that serves all the different kinds of content from that
tations of functionality (e.g. different app that can be app, but this solution sacrifices the (substantial) reused
used to select a contact) are dynamically substitutable. code in the framework that dispatches incoming re-
In addition to the abstract use of service abstrac- quests to different content providers according to the
tions in the inter-app Android framework, there is An- type of content requested. So without the use of ser-
droid framework code within each app that critically vice abstractions, each app would have to reimple-
depends on the service abstraction capabilities of ob- ment this code—ultimately making app interoperabil-
jects. For example, the Android contacts application ity more difficult, and thereby lowering the value of
makes its data available using a ContentProvider the entire ecosystem. This illustrates concretely how
object, a portion of whose interface is shown below.29 objects facilitate reuse: the service abstraction provided
The ContentProvider abstraction is rich, consist- by objects is what enables the content provider frame-
ing of query, insert, update, and delete operations work code to be reused.
(among others). Different kinds of data need different
ContentProviders in order to support queries and Microsoft COM applications and Office plugins. Mi-
other operations in a way that is appropriate to that crosoft COM is an interface standard that enables ap-
kind of data. An app that manages several kinds of plications such as Microsoft Word to communicate
data can therefore define several ContentProviders, with each other and with plugins written by strangers.
and the Android framework must manage them all in An ecosystem has grown up in particular around Mi-
a data structure in order to determine which to use crosoft’s Office suite, with many third-party develop-
when a request for content comes in. Thus, even within ers writing Office plugins, often using Visual Basic to
the application, content providers (and many other ab- conveniently provide a GUI for the plugin. These plu-
stractions) require the features provided by service ab- gins can be dynamically added to Office, where they
stractions. coexist with the native Win32 Office widgets. Many
Pffice plugins either build on other plugins, or incor-
class ContentProvider { porate GUI widgets provided by third parties. The
abstract Cursor query(Uri uri, ...);
result is one of the most robust component market-
abstract int insert(Uri uri,
ContentValues vals);
places in the software industry. Cross-plugin, cross-
abstract Uri update(Uri uri, widget, and cross-language interoperation could not
ContentValues vals, be achieved without the service abstractions provided
...); by Microsoft’s Component Object Model (COM).
abstract int delete(Uri uri, ...); Coppit and Sullivan also studied the reuse achiev-
... // other methods not shown able based on the COM model and its extensions, OLE
} and Active Document [9]. Observing that component-
based software development has largely been elusive,
28 https://www.facebook.com/home
they explore a model in which the components are
29 ContentProvider is actually a class that provides some reusable
not simply libraries, but are full-fledged applications
method implementations (not shown) to subclasses, but the abstract
methods shown here form a subinterface that all content providers
must implement.
themselves, developed by different companies.30 The ods as types [1].31 The definition of the type in the sig-
model was successful, partly due to business factors nature of each module says what the methods are, so
(as with other ecosystems), but also due to technical there is never any question about whether types from
factors such as the interoperability and shared archi- two imported modules match. Thus sharing declara-
tecture provided by COM and related standards. tions are unnecessary. Hence, the use of abstract data
types rather than object types increases coupling be-
4.4 The Architectural Flexibility of Objects tween modules and impedes the flexibility of code.
The problem described above is roughly analogous
Recently, Bracha et al. proposed the Newspeak module to “DLL Hell,” in which a program needs to use two
system, in which every module is parametric in its de- libraries, but those libraries depend on different ver-
pendencies [5]. This design is intended to reduce cou- sions of a third library [30]. Object designs can still
pling between modules, and at the same time subsume suffer from these problems in cases where incompat-
ideas like dependency injection. ible changes are made to an object’s interface between
The Newspeak design stands in contrast to the dis- versions. But where the core interface is compatible,
cussion of fully functorized (i.e. fully parameterized) objects sidestep the problem entirely, because differ-
modules in Harper and Pierce’s chapter on mod- ent implementations of the same (pure) object inter-
ule systems [12]. Harper and Pierce state that “Ex- face will always be interoperable at the type level. To
perience has shown this to be a bad idea: all this the extent that Java programs suffer from an analogous
parameterization—most of it unnecessary—gives rise “JAR Hell,” it may be attributable in part to the fact
to spurious coherence issues, which must be dealt with that Java’s object model is not pure, but rather, as dis-
by explicitly (and tediously) decorating module code cussed by Cook, it contains some support for abstract
with numerous sharing declarations, resulting in a net data types as well.
decrease in clarity and readability for most programs.”
Why is this not a problem for Newspeak?
The obvious answer is that Newspeak is not stati- 5. Conclusion
cally typed, and sharing declarations are about mak- In summary, I have argued that objects provide a
ing sure static types that have to match up, do. But unique form of service abstraction that supports in-
a more subtle examination shows that the problem of teroperable extensions. This interoperability cannot be
proliferating sharing declarations exists only because duplicated in other programming paradigms without
of abstract types. The problem occurs when we have a likewise creating service abstractions, thus simulating
module M that defines an abstract type t, and two dif- the essence of objects. Furthermore, service abstrac-
ferent libraries L1 and L2 depend on module M. The tions are not just of academic interest—they are the
abstract type t may then show up in the signature of foundation of software frameworks and ecosystems,
L1 and L2. Now imagine that we have a program P which arguably constitute the richest form of soft-
that is intended to import L1 and L2, but we wish to ware reuse currently known, and the most significant
make it parametric in the actual implementation of L1 source of value in the software industry, respectively.
and L2. We need the type t that appears in L1 and L2 to Assuming that the market’s adoption of programming
be the same, so that we can pass values of the abstract language technology is even somewhat rational over
type back and forth between L1, L2, and P; in ML, this the long term, these forces ought to be sufficient to
constraint is enforced by a sharing declaration. These make direct language support for service abstractions
declarations proliferate, because if we have n abstract inevitable. This, in turn, explains the rise of object-
types, each of which is shared between m imported oriented programming languages: they represent the
modules, we will have O(n × m) sharing declarations. only class of programming languages to date that pro-
What if all abstractions used object types, rather vides good support for service abstractions.
than abstract data types? If we take Cook’s definition
of objects to be definitive, then an object type does Implications. An implication for future language de-
not denote a particular, but hidden, representation; in- signers is that if a language is to be a suitable founda-
stead, an object type primarily characterizes the set of tion for a software ecosystem, or indeed to support ar-
methods to which an object responds (i.e. a service ab- chitectural reuse in any application domain, it should
straction). This notion of object type is also reflected in have good support for interoperable extensions—and
typed object calculi, many of which use sets of meth- therefore for service abstractions. Left open, for now,

31 While my argument about modularity here focuses on static types,

30 The case study was done with Microsoft Word and Shapeware’s note that the run-time type of an object in a dynamic language can
Visio. Ironically, Microsoft purchased Visio shortly after the case also often be thought of as a set of methods: you get a method-not-
study was completed. understood error if you call a method not in the set.
is what form that support should take: row polymor- Acknowledgments
phism with subtyping as in OCaml, Go’s interfaces, I thank William Cook for inspiring this essay with his
and delegation as in Self appear to support interopera- earlier one, and the many people with whom I have
ble extension just as well as the inheritance constructs informally discussed the arguments in this essay. I also
common to today’s popular industrial languages. Fur- thank Marwan Abi-Antoun, Luı́s Caires, Adam Chli-
thermore, an argument for object-orientation need not pala, Karl Crary, Ray Dillinger, Richard Gabriel, David
be an argument against other paradigms. Good sup- Garlan, Alec Heller, Stefan Holdermans, Ralph John-
port for service abstractions is compatible with good son, James Koppel, Darya Kurilova, Du Li, Michael
support for ADTs, for functional programming, and Maass, Gregory Malecha, Sean McDirmid, Jeff Meis-
for many other desirable language features. ter, Matthew Might, Scott McMurray, Brad Myers,
Predictions. A scientific hypothesis should not only Robb Nebbe, Cyrus Omar, Simon Peyton-Jones, Alex
explain, but also make testable predictions. In that Potanin, Anton van Straaten, Éric Tanter, Philip
spirit, I offer two predictions suggested by the hypoth- Wadler, Todd Wilson, John Zabroski, and the anony-
esis described above concerning the reasons behind the mous reviewers for comments and suggestions on ear-
success of objects. The following hypotheses can be lier drafts of this essay.
tested either by experiment, or in the natural course of The writing of this essay was supported by the
the future evolution of software, languages, and tools: U.S. National Science Foundation under grant #CCF-
1116907, “Foundations of Permission-Based Object-
Oriented Languages,” the U.S. Department of Defense,
and the Air Force Research Laboratory.
• Lightweight, first-class modules are service abstrac-
tions in that they provide unanticipated extension References
of rich abstractions, and interoperability of the ex-
[1] M. Abadi and L. Cardelli. A Theory of Objects. Springer-
tensions via module signature subtyping. If such a
Verlag, 1996.
module system is added to a language, such as Stan-
[2] E. Biagioni, R. Harper, and P. Lee. A network protocol
dard ML, that does not currently have good sup-
stack in Standard ML. Higher Order Symbolic Comput., 14
port for objects, framework-like designs will begin
(4):309–356, Dec. 2001.
to show up in the enhanced language.
[3] D. G. Bobrow, K. Kahn, G. Kiczales, L. Masinter, M. Ste-
• A practical, statically typed object-oriented lan- fik, and F. Zdybel. CommonLoops: Merging Lisp and
guage can be designed to support Newspeak-style object-oriented programming. In Object-Oriented Pro-
modules that are parametric in their dependen- gramming Systems, Languages, and Applications, 1986.
cies, provided that all types are given in an object- [4] J. Bosch. From software product lines to software
oriented, rather than an ADT, style. ecosystems. In Software Product Line Conference, 2009.
[5] G. Bracha, P. von der Ahé, V. Bykov, Y. Kashai, W. Mad-
dox, and E. Miranda. Modules as objects in Newspeak.
In European Conference on Object-Oriented Programming,
Future work. There is much more to be done in explor- 2010.
ing the potential benefits (or lack thereof) of objects. I [6] N. Brown. Object-oriented design patterns in the kernel,
have focused on technical benefits, but non-technical part 1. Linux Weekly News, 2011. URL http://lwn.
benefits (e.g. of a psychological nature) may be impor- net/Articles/444910/.
tant too. Furthermore, I have focused on service ab- [7] K. Bruce, L. Cardelli, and B. Pierce. Comparing object
stractions as representing the core of objects, but in encodings. In Theoretical Aspects of Computer Software.
doing so I have neglected other interesting features of 1997.
typical object-oriented programming languages. Tem- [8] W. R. Cook. On understanding data abstraction, revis-
pero et al. have shown that a broad range of object- ited. In Onward! Essays, 2009.
oriented programs use inheritance frequently and in [9] D. Coppit and K. J. Sullivan. Multiple mass-market
non-trivial ways [31]; more research is needed to bet- applications as components. In International Conference
ter understand the benefits (and possible drawbacks) on Software Engineering, 2000.
of inheritance, and to explain why it is so widely used. [10] M. Fayad and D. C. Schmidt. Object-oriented appli-
It is my hope that the argument, hypotheses, and cation frameworks. Commun. ACM, 40(10):32–38, Oct.
predictions above will be further tested and refined in 1997.
future research, ultimately contributing to a broader [11] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. De-
and deeper understanding of the role service abstrac- sign Patterns: Elements of Reusable Object-Oriented Soft-
tions play in modern software systems. ware. Addison-Wesley, 1994.
[12] R. Harper and B. C. Pierce. Design considerations for [28] A. Schwill. Cognitive aspects of object-oriented pro-
ML-style module systems. In B. C. Pierce, editor, Ad- gramming. In IFIP WG 3.1 Working Conference “Integrat-
vanced Topics in Types and Programming Languages. MIT ing Information Technology into Education”, 1994.
Press, 2004. [29] A. Stepanov. STLport: An interview with A.
[13] T. Hoare. Null references: The billion dollar mistake. In Stepanov. Available at http://www.stlport.org/
QCon London, 2009. resources/StepanovUSA.html.
[14] C. N. C. Jaspan. Proper plugin protocols. Carnegie Mel- [30] C. Szyperski. Greetings from DLL hell. Dr. Dobbs Journal,
lon University Ph.D. Dissertation, available as technical Oct. 1999.
report CMU-ISR-11-116, 2011. [31] E. Tempero, H. Yang, and J. Noble. What programmers
[15] R. E. Johnson. Frameworks = (components + patterns). do with inheritance in Java. In European Conference on
Commun. ACM, 40(10):39–42, Oct. 1997. Object-Oriented Programming, 2013.
[16] R. E. Johnson and B. Foote. Designing reusable classes. [32] D. Ungar and R. B. Smith. Self: The power of simplicity.
Journal of Object-Oriented Programming, 1(2):22–35, 1988. In Object-oriented programming systems, languages, and ap-
[17] M. L. Katz and C. Shapiro. Network externalities, com- plications, 1987.
petition, and compatibility. The American Economic Re- [33] J. Vlissides. Protection, part 1: The Hollywood principle.
view, 75(3):424–440, 1985. C++ Report, Feb. 1996.
[18] A. C. Kay. The early history of Smalltalk. In History of [34] P. Wadler and S. Blott. How to make ad-hoc polymor-
programming languages—II, 1993. phism less ad hoc. In Principles of Programming Lan-
[19] O. Kiselyov and R. Lämmel. Haskell’s overlooked object guages, 1989.
system. Manuscript available at http://arxiv.org/
abs/cs/0509027, 2005.
A. Supporting Data
[20] C. Lattner and V. Adve. LLVM: A compilation frame-
work for lifelong program analysis & transformation. In As of 4/7/2013, LangPop.com’s top languages were, in
Code Generation and Optimization, 2004. order: C, Java, C++, PHP, JavaScript, Python, C#, Perl,
[21] O. Lehrmann Madsen, B. Møller-Pedersen, and K. Ny-
SQL, and Ruby. All of these languages except C and
gaard. Object-oriented programming in the BETA program- SQL have object-oriented features. The Wikipedia page
ming language. ACM Press/Addison-Wesley, 1993. on Object-Oriented Programming32 describes Java,
[22] B. Liskov. A history of CLU. In History of programming
C++, JavaScript, Python, C#, and Ruby as being pri-
languages—II, 1993. marily object-oriented languages; PHP and Perl have
object-oriented features but were designed (and are
[23] R. Love. Linux Kernel Development (2nd Edition). Novell,
2nd edition edition, 2005.
still probably used) primarily for procedural program-
ming.
[24] B. Meyer. Object-Oriented Software Construction. Prentice-
At the same date, the corresponding top languages
Hall, 1988.
at the TIOBE index were, in order: C, Java, C++,
[25] D. R. Musser and A. A. Stepanov. Generic program- Objective-C, C#, PHP, (Visual) Basic, Python, and Perl.
ming. In International Symposium on Symbolic and Alge-
All but C have object-oriented features, and I consider
braic Computation, 1988.
all but C, PHP, Perl, and (Visual) Basic to be primarily
[26] D. L. Parnas. On the criteria to be used in decomposing object-oriented.
systems into modules. Communications of the ACM, 15
(12):1053–1058, 1972.
[27] J. C. Reynolds. User-defined types and procedural data
structures as complementary approaches to data ab-
straction. In New Advances in Algorithmic Languages,
1975.

32 http://en.wikipedia.org/wiki/Object-oriented_

programming