
Article 598 of 598, Tue 22:18.
Subject: Evaluating "Object-Oriented" Programming Languages
Keywords: object-oriented, programming languages, evaluation, bibliography
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Path: haven!purdue!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
Newsgroups: comp.object
Date: 3 Jan 90 03:18:09 GMT


	"Give us the tools, and we will finish the job."

	-- Winston Churchill (February 9, 1941)

	"We dissect nature along lines laid down by our native
	language ... Language is not simply a reporting device for
	experience but a defining framework for it."

	-- Benjamin Whorf (1897 - 1941) in "Thinking in Primitive
	   Communities"

			       PROLOGUE

Object-oriented software engineering (OOSE) is an extremely hot topic.
There is a rapidly-increasing number of books, articles, seminars,
conferences, and products which focus on the technology. Only a few
years ago, the discussion was largely limited to programming language
features. Now, however, software engineers are investigating and using
such things as "object-oriented requirements analysis" (OORA),
"object-oriented design" (OOD), "object-oriented database management
systems" (OODBMS), "object-oriented computer hardware" (OOCH), and
"object-oriented computer aided software engineering" (OO CASE).

The character of object-oriented applications has changed. Originally,
most object-oriented applications were small and non-critical.
Object-oriented software engineering was chiefly experimental, i.e.,
not production-oriented Slow programming language interpreters, highly
non-portable languages and environments, lack of concurrency-related
features, and fairly limited access to low-level machine
characteristics were all tolerable.

Now, object-oriented software engineering is entering the mainstream.
Object-oriented technology must demonstrate its suitability for
applications which are both large and critical. Software engineers
must adapt object-oriented concepts to consider such issues as
efficiency, low-level hardware characteristics, portability, and
concurrency. They must do this in a way which preserves the desirable
features, and the essence, of the object-oriented paradigm.

In each object-oriented application, one of the tools that will have
to be considered is, of course, the implementation language. At one
time, the choice was simple -- there was only one language (i.e.,
Smalltalk) which claimed to be "object-oriented." Now there are scores
of languages, and a plethora of variants, all of which claim to be
object-oriented. The issue is further complicated by those who
advocate the (occasional) use of traditionally "non-object-oriented"
programming languages in object-oriented applications.

			HISTORICAL BACKGROUND

In the very early 1970s, things were simple. There was only one
programming language which called itself "object-oriented," i.e.,
Smalltalk ([Goldberg and Robson, 1983]). Further, all that anyone
seemed interested in was "object-oriented programming" (OOP). No one
even suggested such things as "object-oriented design" (OOD) or
"object-oriented requirements analysis" (OORA).

In the 1980s, there was an explosive growth in object-oriented
programming languages. Initially, most of these languages attempted to
define themselves in terms of the Smalltalk paradigm. As our
understanding of object-oriented concepts matured, however, the
deviations from Smalltalk concepts among so-called "object-oriented
programming languages" (OOPL) became more pronounced.

[The 1980s also saw the birth and evolution of OOD, OORA,
object-oriented domain analysis (OODA), and object-oriented database
management systems (OODBMS). As our understanding and usage of OOPLs
increased, so did our understanding of object-oriented software
engineering (OOSE) in general.]

By the late 1980s, there was not only an increased interest in OOPLs,
but also an increased interest in:

	- attempts to evaluate, classify, or justify a given
	  programming language as being "object-oriented," e.g.,
	  [Bach, 1988], [Buzzard and Mudge, 1985], [Cook, 1986],
	  [Touati, 1987], and [Wolf, 1989]

	- adding, or suggesting, "object-oriented extensions" to
	  existing programming languages, e.g., [Bergin and
	  Greenfield, 1988], [Cox, 1986], [Di Maio et al, 1989],
	  [Donaldson, 1989], [Forestier et al, 1989], [Moon, 1986],
	  [Simonian and Crone, 1988a], [Simonian and Crone, 1988b],
	  [Waurzyniak, 1989], and [Wegner, 1983]

	- developing applications using an object-oriented approach,
	  but using traditionally "non-object-oriented," programming
	  languages, e.g., [Edelson, 1987], [Jacky and Kalet, 1987],
	  and [Zaniolo, 1984].

All of this has stimulated efforts to define the criteria for calling
a language an object-oriented programming language. For example, Peter
Wegner, in [Wegner, 1986], offered:

	"We define 'object-oriented' so that it includes
	prototypical object-oriented languages like Smalltalk and
	Loops, but excludes languages like Ada, Modula, and Clu which
	have data abstractions but are not generally considered
	object-oriented. Support of data abstraction is a necessary
	but not sufficient condition for a language to be
	object-oriented. Object-oriented languages must additionally
	support both the management of collections of data
	abstractions by requiring data abstractions to have a type,
	and the composition of abstract data types through an
	inheritance mechanism:

	"object-oriented = data abstraction + abstract data types +
	type inheritance."

[There have been a number of good overview articles describing the
characteristics found in many different object-oriented programming
languages, e.g. [Stefik and Bobrow, 1985], [Wegner, 1987a], [Wegner,
1987b], and [Wegner, 1989]. The reader should be aware that not all
authors agree on "the basics," and that the technology is constantly
evolving.]

However, there are a good many problems which arise when people
attempt to classify a particular programming language as either
object-oriented or non-object-oriented.

		      PROBLEMS WITH EVALUATIONS

Some "litmus tests" for object-oriented programming languages are
based on how close a programming language is in concept and
implementation to Smalltalk. There are obvious problems with this
approach, e.g., since a language which is not Smalltalk must differ
from Smalltalk in some (usually significant) ways, what are acceptable
deviations? Further, as we begin to understand more about the
object-oriented paradigm, some people have begun to point out
"deficiencies" in Smalltalk, for example, the lack of type checking
(see, e.g., [Johnson, 1986]). Is a programming language which
"corrects" these deficiencies more object-oriented than even Smalltalk
itself?

A major source of problems in any comparison scheme is the confusion
between concepts and implementations. For example, in Smalltalk,
objects communicate (i.e., work gets done) via "message passing."
Messages are sent from one object to another. CLOS ([Keene, 1989]),
does not have message passing in the Smalltalk sense, but instead uses
a generalization that is more Lisp-like, i.e., generic functions. Is
this an acceptable "deviation?" The important question here is: when
physical differences arise, how great must these differences be before
"reasonable people" can agree that the differences are not only
physical differences, but also conceptual differences.

The greatest problem is determining just what "object-oriented
characteristics" a programming language must possess to be considered
a "true" OOPL. There are more than a few contenders for
object-oriented programming language characteristics, e.g.:

	- Encapsulation: Encapsulation is the localization and binding
	  together of items. In languages such as Smalltalk, the
	  encapsulation is physical, i.e., it is accomplished via the
	  syntax and semantics of the language. For example, Smalltalk
	  offers a "class" construct which allows a programmer to
	  physically encapsulate the the methods, operations, and
	  other features which logically constitute a class.

	  The Common Lisp Object System (CLOS), on the other hand,
	  does not provide much physical encapsulation, and instead
	  emphasizes logical encapsulation. (See, e.g., [Gabriel,
	  1989] and [Keene, 1989].)

	- Information hiding: Information hiding is the suppression of
	  (hopefully) unnecessary details. Most commonly, the idea is
	  to reveal details at a given level of abstraction, and to
	  hide, or cover up, details at lower levels of abstraction.
	  In Smalltalk, objects are black boxes, i.e., their internal
	  structures and implementations are hidden from those outside
	  of the object. (To be technically accurate, they are hidden
	  from objects which are outside of the object's
	  subclass-superclass chain.)

	  C++ ([Stroustrup, 1986]), on the other hand, allows
	  "violations" of strict information hiding via friend
	  functions. These functions allow objects to have access to
	  the internals of other objects. Flavors ([Moon, 1986]) and
	  LOOPS ([Bobrow, 1983]) allow instances to directly access
	  the internals of other objects.

	- Data abstraction: Data abstraction is a form of abstraction
	  where the details of the underlying algorithms are hidden
	  (i.e., they are an abstraction), and the type of data which
	  those algorithms manipulate is also a high-level concept,
	  i.e. an abstraction. Data abstraction allows objects to be
	  treated as black boxes, e.g., "name objects" may be added to
	  "directory objects" without regard to the underlying
	  implementation of the name objects. (See, e.g., [Liskov,
	  1988].) Data abstraction is implemented directly in
	  languages such as Simula ([Dahl and Nygaard, 1966]),
	  Smalltalk, Ada, Modula ([Wirth, 1983]), and Clu ([Liskov et
	  al, 1977]), but is not directly available in common
	  programming languages, e.g., C, Pascal, Fortran, and Cobol.

	  Data abstraction is also necessary for the implementation of
	  metaclasses. A metaclass is a class whose instances are
	  themselves classes.  Some object-oriented programming
	  languages (e.g., C++ and Trellis ([Schaffert et al, 1986]))
	  do not allow for straightforward implementation of
	  user-defined metaclasses.

	- Inheritance: Inheritance is a mechanism whereby a subclass
	  acquires characteristics from its immediate superclass, and,
	  by induction, from all of its antecedent superclasses.
	  Inheritance is implemented in a dynamic manner in languages
	  such as Smalltalk and C++, but may also be accomplished via
	  other mechanisms, e.g., via preprocessors ([Donaldson,
	  1989]) or using existing features of a language ([Perez,
	  1988]). The chief question seems to be: "must a given
	  programming language implement inheritance in exactly the
	  same manner as Smalltalk to be considered object-oriented?"

	  In some "classless" object-oriented languages (e.g., Self
	  ([Unger and Smith, 1987])), mechanisms which differ
	  (slightly) from inheritance (e.g., delegation) are used.
	  There have been attempts to reconcile these differing
	  mechanisms, e.g., the "Treaty of Orlando" ([Lieberman et al,
	  1988]). There are also extensions of the Smalltalk type of
	  inheritance. For example, Smalltalk has only single
	  inheritance (i.e., each subclass has exactly one immediate
	  superclass), and Eiffel ([Meyer, 1987]) supports multiple
	  inheritance (i.e., each subclass may have more than one
	  immediate superclass).

	  Some have observed that Smalltalk-like inheritance can
	  mitigate some of the benefits of encapsulation, e.g.,
	  [Snyder, 1986]. Further, Smalltalk-like inheritance can have
	  undesirable side-effects when changes are made to the
	  subclass-superclass hierarchy.

	- Classes: A class is an object which is used to create
	  instances, where an instance is a specific thing or
	  characteristic. More precisely, a class is a template,
	  description, pattern, or "blueprint" for a category of very
	  similar items. Among other things, a class describes the
	  interface these items will present to the outside world.
	  Classes first appeared in Simula, and are called "classes"
	  in languages such as Smalltalk, C++, and Eiffel ([Meyer,
	  1987]).

	  Some object-oriented programming languages specifically
	  avoid classes. For example, David Unger's Self uses no
	  classes, and creates new objects from existing
	  (prototypical) objects. Beta ([Kristensen et al, 1987])
	  "replaces classes, procedures, functions, and types by a
	  single abstraction mechanism called the pattern." Actor
	  languages (e.g., [Agha, 1986]) lack both classes and an
	  inheritance mechanism.

	- Types: Whereas a class defines the structure and
	  characteristics of its instances, a type defines those
	  operations in which an object may participate, and under
	  what circumstances the object may legally participate in
	  those operations. Types are a relatively new concept in
	  object-oriented programming. Smalltalk has, in effect, no
	  types, but there are typed extensions to Smalltalk, e.g.,
	  [Johnson, 1986]. C++ also supports some typing, i.e., more
	  than C, and much less than Ada ([DoD, 1983]).

	- Static Versus Dynamic Binding: Binding is the association of
	  allowable operands (i.e., objects) with operations. Binding
	  may be either static (or early), i.e., accomplished at
	  compile time, or dynamic (or late), i.e., accomplished at
	  run-time. Until the introduction of Objective-C ([Cox,
	  1986]), there was little, if any, discussion of "binding"
	  within the object-oriented community.

	  Static binding is usually associated with strongly typed
	  programming languages, and dynamic binding with weakly-typed
	  programming languages. Smalltalk and Objective-C support
	  dynamic binding.

	- Message passing: In Smalltalk, work is accomplished by
	  message passing. Messages have a prescribed format, and are
	  handled in a specified manner. However, Wegner ([Wegner,
	  1987], page 512) observes: "... the term "message passing"
	  has several different meanings. The first object-oriented
	  language, Simula, had coroutines, an asynchronous
	  (quasi-parallel) form of message-passing in which the sender
	  saves its state and must be explicitly reawakened by a
	  resume call rather than by an automatic reply from the
	  receiver. Smalltalk and Loops equate message-passing with
	  remote procedure calls, a synchronous form of
	  message-passing in which the sender must wait for a reply
	  form the receiver before continuing. Modules in distributed
	  systems may communicate by rendezvous, which combines remote
	  procedure call with synchronization between the calling and
	  called processes by asynchronous message-passing, or both."

	  Wegner continues, "Objects certainly need to communicate,
	  but any form of message-passing appears to be compatible
	  with object-oriented programming."

	- Polymorphism: Polymorphism is a measure of the degree of
	  difference in how each item in a specified collection of
	  items must be treated at a given level of abstraction.
	  Polymorphism is increased when any unnecessary differences,
	  at any level of abstraction, within a collection of items
	  are eliminated. (See [Gabriel, 1989], [Harland, 1984],
	  [Milner, 1978] and [Milner, 1984].) Most often we hear
	  discussions of polymorphism in terms of "overloading of
	  operation names or designators," i.e., which particular
	  method (algorithm) will be used for a given operation, given
	  a specific operand (or operands). [Polymorphism is, of
	  course, a much broader concept.] Using the operation/operand
	  theme, we can provide examples of several different types of
	  polymorphism, i.e.:

		- general polymorphism -- where the same method is
		  used regardless of the type (or form) of the
		  operands,

		- ad hoc polymorphism -- where a different method is
		  selected based on the type (or form) of the
		  operands, and

		- parameterized polymorphism -- where the user of the
		  polymorphic abstraction must supply some
		  information, in the form of parameters, to the
		  abstraction.

	  In truth, even such languages as Fortran are somewhat
	  polymorphic, e.g., the same addition operator ("+") is used
	  for both integers and reals, although the method for each is
	  different. However, it is the polymorphic extensions, and
	  the ability to have user-defined polymorphic relationships,
	  which are attractive in many object-oriented languages.
	  [Few, if any, object-oriented languages are as polymorphic
	  as the ML language ([Milner, 1984]).]

	- Persistence: Persistence is a measure of the volatility of
	  the state of an object. In object-oriented circles,
	  persistence is most often discussed in the context of
	  distributed applications (e.g., [Low, 1988]), or, more
	  commonly, in the context of object stores or databases
	  (e.g., [Merrow and Laursen, 1987]). Although some people
	  feel that persistence should be integrated into the
	  programming language itself (e.g., [Atkinson et al, 1983]),
	  this is not a very strong contender for a necessary
	  characteristic of object-oriented programming languages.

	- Concurrency: One very important requirement for any
	  object-oriented application is that it closely model the
	  "real world," and the real world is usually highly
	  concurrent (as opposed to strictly sequential). Smalltalk is
	  decidedly strictly sequential. There are, however, a number
	  of concurrent object-oriented programming languages, e.g.,
	  Vulcan ([Kahn et al, 1987]), ABCL/1 ([Yonezawa et al,
	  1986]), and POOL-T ([America, 1987]). Unfortunately, none of
	  these "concurrent object-oriented programming languages"
	  appears headed for the mainstream.

	- Reflection: Reflection is a process whereby a system knows
	  about itself as a computational, or structural, entity, and
	  has the capability to act on this knowledge. (See, e.g.,
	  [Ferber, 1989].) Reflection has been suggested as one method
	  for dealing with concurrency in object-oriented systems.
	  Very few, if any, people would include reflection as a
	  minimum characteristic for an object-oriented programming
	  language.

	- Object-composition: Depending on who you are talking to, an
	  object can be a class, a metaclass, an instance, or some
	  other item. The classic concept of an object is that it is a
	  complete entity, having (at least the possibility of) the
	  ability to maintain state, presenting a specified interface
	  to the outside world, and hiding its internal
	  implementation. Commonly used examples of objects include
	  bank accounts, temperature sensors, stacks, and voltage.

	  Functional object-oriented programming languages, e.g.,
	  FOOPS ([Goguen and Meseguer, 1987]), allow "functions" to be
	  objects. "Traits" ([Curry and Ayers, 1984]), "mixins"
	  ([Smith et al, 1987] and [Stefik and Bobrow, 1985]), and
	  "partial types" ([Halbert and O'Brien, 1987]) allow for
	  the implementation of partial concepts as objects.

Peter Wegner ([Wegner, 1987b]) suggests the following "dimensions" of
object-oriented language design:

	- objects

	- classes (object types)

	- inheritance

	- data abstraction

	- strong typing

	- concurrency

	- persistence

He claims that these characteristics "span the design space of
object-based languages." He also observes ([Wegner, 1987a])
"object-based languages must possess the first," i.e. objects, and
that certain combinations of the above attributes may be incompatible.

Even if a general agreement on object-oriented characteristics can be
reached, there are other problems with the evaluation of a programming
language for object-oriented software engineering. Very often, all the
characteristics are given equal weight -- although many, if not most,
people have their own intuitive ranking of the importance of each
characteristic. A variation on this problem is the "all or nothing"
syndrome, i.e., if a programming language is missing, or has a poor
implementation of, even one characteristic, the programming language
is not considered object-oriented.

Bigotry is often a major problem with programming language evaluation.
Software engineers are, after all, human beings, and are thus subject
to human frailties. I have read quite a number of evaluations and
comparisons of programming languages, and I would have a hard time
trying to identify even one which was totally free of bias.
Unfortunately, I have read too many which do little to hide their
strong (non-technical) prejudice against a particular language.

Sloppiness is another major problem with evaluations. Many times I
have gotten the distinct impression that the authors of the evaluation
have not used, or even looked at, the programming languages they are
evaluating. Sometimes they seem to have scanned a list of reserved
words, and, not finding words such as "object" or "class," they assume
the language does not support object-oriented programming.

Another problem is the confusion about the original goals for the
programming language itself. Specifically, very few programming
languages were created solely with the idea of implementing a pure
object-oriented programming language. For example, the Ada programming
language was implemented for large, real-time, embedded applications,
where reliability is critical. Some of the thinking behind Ada
conflicts with some of the traditional object-oriented implementation
philosophy.

			EVALUATION METHODOLOGY

Sometimes the evaluation criteria for an object-oriented programming
language seems biased in one direction, e.g., "how many of
Smalltalk's features does this language possess?" As part of the
evaluation of any candidate language for object-oriented software
engineering, I propose that three main questions be asked, viz:

	1. What features does the candidate programming language have
	   that most "object-oriented" programming languages seem to
	   lack?

	2. What features does the candidate programming language have
	   in common with most "object-oriented" programming
	   languages?

	3. What features do most "object-oriented" programming
	   languages have that the candidate programming language
	   seems to lack?

Using the Ada programming language as an example, let us provide some
sample answers to these questions. (Please note that we are not saying
that Ada is better than X, or that Ada is not as good as Y. We are
merely using the language as an example.):

	- Under the category of features that Ada possesses, and that
	  most object-oriented programming languages seem to lack we
	  have, for example:

		- the capability of creating user-defined metaclasses.
		  Assuming that one can fashion a class in Ada using a
		  package which exports a type, for example, a
		  metaclass can be created by making that package
		  generic.

		- exceptions (see, e.g., [Dony, 1988]). Ada provides
		  both language-defined exceptions, and the capability
		  for user defined exceptions. (I should point out
		  that Ada's exception mechanism differs from that
		  found in some object-oriented programming languages,
		  e.g., Mesa ([Mitchell et al, 1979]).)

		- concurrency. Ada provides concurrency via its
		  tasking mechanism. While it is true that there are a
		  growing number of concurrent object-oriented
		  programming languages, the most popular
		  object-oriented programming languages still lack
		  concurrency, or a mature, well-understood means for
		  handling concurrency.

		- types (strong typing). Many people have complained
		  about Ada's strong typing. This makes the trend
		  towards more strongly typed object-oriented
		  programming languages that much more ironic.

		- the ability to address low-level, machine-dependent
		  items. Ada provides access to low-level aspects of
		  the environment via such things as representation
		  clauses. Few of the most popular object-oriented
		  programming languages directly allow access to
		  low-level, machine-dependent items. For example,
		  while C++ does seem to provide some access to the
		  hardware, Smalltalk and Eiffel generally avoid the
		  issue.

		- a high degree of portability. Many programmers
		  confuse "compilability" with "portability." Just
		  because there are many implementations of a compiler
		  for a given language, does not mean that they will
		  all compile the same code, or that the compiled code
		  will exhibit the same semantics. (In truth, the main
		  reason for the possibility of producing highly
		  portable Ada source code, has more to do with the
		  infrastructure of Ada technology (e.g., validation)
		  than with the language itself.)

	- Under the category of features that Ada shares in common
	  with most object-oriented programming languages we have, for
	  example:

		- encapsulation: Ada's package construct allows for
		  the encapsulation of operations, methods,
		  exceptions, constants, and other items which can be
		  associated with an object (e.g., a class, an
		  instance, or a metaclass).

		- information hiding: Ada's private types provide
		  an excellent mechanism for hiding information.

		- data abstraction: Ada's generics afford a
		  software engineer the capability to make both
		  subprograms and packages generic. Used well, they
		  make the implementation of data abstraction fairly
		  easy.

		- some types of polymorphism: Ada's ability to
		  overload operators, and names, as well as Ada's
		  ability to parameterize generic packages provide
		  some level of software engineer controlled
		  polymorphism.

	- Under the category of features that Ada lacks in comparison
	  with most object-oriented programming languages we have, for
	  example:

		- Smalltalk-like inheritance mechanism: No claim can
		  be made that Ada, in isolation, closely mirrors
		  Smalltalk-like inheritance. There are ways of
		  simulating this mechanism within the language (e.g.,
		  [Perez, 1988]), and ways to implement a static
		  "layers of abstraction" approach to inheritance. (We
		  should also note that there is a distinct difference
		  between genericity (provided by Ada's generics)
		  and inheritance. See, e.g., [Meyer, 1986].)

		- some forms of polymorphism: The Ada language is not
		  as polymorphic as Lisp and its object-oriented
		  derivatives (e.g., Flavors), and nowhere near as
		  polymorphic as ML ([Milner, 1984]). Being a very
		  strongly typed language, some forms of polymorphism
		  (e.g., arrays with components of different types)
		  are precluded by definition. (Yes, there are ways
		  around this using, for example, variant records or
		  access types and unchecked_conversion, but these are
		  not direct methods.)

		- dynamic binding: Ada's emphasis on reliability
		  shifts part of the burden to the programming
		  language itself. In languages which feature dynamic
		  binding (e.g., Objective-C ([Cox, 1986])), the onus
		  is more on the software engineer, and less on the
		  language, in terms of reliability. Therefore,
		  dynamic binding is an attribute which directly
		  conflicts with the original intentions of the Ada
		  language.

		- some types of parameters: Not all Ada objects are
		  first-class objects. For example, objects
		  implemented using types exported from (generic)
		  packages, and objects implemented using task types
		  can participate in a quite a number of expressions,
		  and can be passed as parameters. However objects
		  implemented using objects exported from packages,
		  and objects implemented using tasks (and not task
		  types) cannot behave as first class objects.
		  Further, Ada's current non-support (or extremely
		  limited support) for such items as "package types,"
		  "subprogram types," "procedure parameters," and
		  "exceptions as parameters," precludes some types of
		  desirable polymorphic behavior.

[Note: A number of extensions to the Ada language (e.g., DRAGOON ([Di
Maio et al, 1989]), Classic Ada ([Donaldson, 1989]), Ada++ ([Forestier
et al, 1989]), and InnovAda ([Simonian and Crone, 1988a])) do address
each of these points. However, they are not part of the current
language definition ([DoD, 1983]).]

Of course, there are other considerations in the choice of an
implementation language e.g., availability on the desired platforms,
interfacing to other applications, customer requirements, and staff
training.

If one is developing a small and/or non-critical application, then all
that may be required is object-oriented programming (coding). However,
for large and/or critical applications, it is likely that one, or
more, of the following may be necessary: object-oriented design (OOD),
object-oriented requirements analysis (OORA), and object-oriented
domain analysis (OODA). In addition, object-oriented thinking will
permeate post-development life-cycle activities, management practices,
development standards, organizational policies and procedures, and
software quality assurance, among others.

This is an important point. As we move away from the myopic view of
considering what goes on during coding, and move towards a more
comprehensive (e.g., total life-cycle) perspective on software
engineering, our evaluation criteria for an object-oriented
programming language changes. Potential flaws, which were virtually
unnoticed during programming-in-the-small, become glaring deficiencies
in software-engineering-in-the-large.

It is crucial that a given programming language closely mirror the
thought processes which were introduced during requirements analysis,
and carried over to design. For example, if we find it natural to talk
about metaclasses during analysis and design, it is more than a little
helpful if our implementation language allows us to implement
metaclasses directly. The same is true for concepts such as
concurrency and inheritance.

			      CONCLUSION

Deciding whether a given programming is "object-oriented" is not as
simple as some people would have it. However, if each organization, or
installation, is aware of the issues, and the scope of their
object-oriented software engineering efforts, then intelligent choices
can be made.

Of course, this article can provide some fodder for academic
evaluation, and net discussion as well.

This is probably the biggest article I have submitted to comp.object.
I'll try to cut back on the size of future articles. Thank you for
listening.

				-- Ed Berard
				   Berard Software Engineering, Inc.
				   18620 Mateney Road
				   Germantown, Maryland 20874
				   Phone: (301) 353-9652
				   FAX:   (301) 353-9272

			     BIBLIOGRAPHY

[Agha, 1986]. G. Agha, "An Overview of Actor Languages," SIGPLAN
Notices, Vol. 18, No. 6, June 1983, pp. 58 - 67.

[America, 1987]. P. America, "POOL-T: A Parallel Object-Oriented
Language," in Object-Oriented Concurrent Programming, A. Yonezawa and
M. Tokoro, Editors, MIT Press, Cambridge, Massachusetts, 1987, pp. 199
- 220.

[Atkinson et al, 1983]. M.P. Atkinson, P.J. Bailey, W.P. Cockshott,
K.J. Chisholm, and R. Morrison, "An Approach to Persistent
Programming," Computer Journal, Vol. 26, No. 4, 1983, pp. 360 - 365.

[Bach, 1988]. W.W. Bach, "Is Ada Really an Object-Oriented Programming
Language," Proceedings of Ada Expo 1988, Galaxy Productions,
Frederick, Maryland, 1988, 7 pages.

[Bailin, 1988]. S.C. Bailin, "An Object-Oriented Specification Method
for Ada," Proceedings of the Fifth Washington Ada Symposium, June 27 -
30, 1988, Association for Computing Machinery, New York, New York,
1988, pp. 139 - 150.

[Bergin and Greenfield, 1988]. J. Bergin and S. Greenfield, "What Does
Modula-2 Need to Fully Support Object-Oriented Programming?," SIGPLAN
Notices, Vol. 23, No. 3, March 1988, pp. 73 - 82.

[Bobrow, 1983]. D.G. Bobrow, The LOOPS Manual, Rank Xerox, Inc., Palo
Alto, California, 1983.

[Buzzard and Mudge, 1985]. G.D. Buzzard and T.N. Mudge, "Object-Based
Computing and the Ada Programming Language," IEEE Computer, Vol. 18,
No. 3, March 1985, pp. 12 - 19.

[Cook, 1986]. S. Cook, "Languages and Object-Oriented Programming,"
Software Engineering Journal, Vol. 1, No. 2, 1986, pp. 73 - 80.

[Cox, 1986]. B.J. Cox, Object Oriented Programming: An Evolutionary
Approach, Addison-Wesley, Reading, Massachusetts, 1986.

[Curry and Ayers, 1984]. G.A. Curry and R.M. Ayers, "Experience with
Traits in the Xerox Star Workstation," IEEE Transactions on Software
Engineering, Vol. SE-10, No. 5, September 1984, pp. 519 - 527.

[Dahl and Nygaard, 1966]. O.J. Dahl and K. Nygaard, "SIMULA -- an
ALGOL-Based Simulation Language," Communications of the ACM, Vol. 9,
No. 9, September 1966, pp. 671 - 678.

[Di Maio et al, 1989]. A. Di Maio, C. Cardigno, R. Bayan, C.
Destombes, and C. Atkinson, "DRAGOON: An Ada-Based Object-Oriented
Language," Ada: the Design Choice -- Proceedings of the Ada-Europe
Conference, Madrid 13-15 June 1989, Cambridge University Press,
Cambridge, United Kingdom, 1989, pp. 39 - 48.

[DoD, 1983]. Reference Manual for the Ada Programming Language,
(ANSI/MIL-STD-1815A-1983), Government Printing Office, Washington,
D.C., 1983.

[Donaldson, 1989]. C.M. Donaldson, "Dynamic Binding and Inheritance in
an Object-Oriented Ada Design," Ada: the Design Choice -- Proceedings
of the Ada-Europe Conference, Madrid 13-15 June 1989, Cambridge
University Press, Cambridge, United Kingdom, 1989, pp. 16 - 25.

[Dony, 1988]. C. Dony, "An Object-Oriented Exception Handling System
for an Object-Oriented Language," ECOOP '88: Proceedings of the
European Conference on Object-Oriented Programming, Lecture Note on
Computer Science, Volume 322, Springer Verlag, New York, New York,
1988, pp. 146 - 161.

[Edelson, 1987]. D.R. Edelson, "How Objective Mechanisms Facilitate
the Development of Large Software Systems in Three Programming
Languages," SIGPLAN Notices, Vol. 22, No. 9, September 1987, pp. 54 -
63.

[Ferber, 1989]. J. Ferber, "Computational Reflection In Class Based
Object-Oriented Languages," OOPSLA '89 Conference Proceedings,
Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp.
317 - 326.

[Forestier et al, 1989]. J.P. Forestier, C. Fornarino, and P.
Franchi-Zannettacci, "Ada++: A Class and Inheritance Extension for
Ada," Ada: the Design Choice -- Proceedings of the Ada-Europe
Conference, Madrid 13-15 June 1989, Cambridge University Press,
Cambridge, United Kingdom, 1989, pp. 3 - 15.

[Gabriel, 1989]. R.P. Gabriel, "Using the Common LISP Object System,"
Computer Language, Vol. 6, No.8, August 1989, pp. 73 - 80.

[Goguen and Meseguer, 1987]. J.A. Goguen and J. Meseguer, "Unifying
Functional, Object-Oriented and Relational Programming With Logical
Semantics," in Research Directions in Object-Oriented Programming, B.
Shriver and P. Wegner, Editors, The MIT Press, Cambridge,
Massachusetts, 1987, pp. 417 - 477.

[Goldberg and Robson, 1983]. A. Goldberg and D. Robson, Smalltalk-80:
The Language and Its Implementation, Addison-Wesley, Reading,
Massachusetts, 1983.

[Halbert and O'Brien, 1987]. D.C. Halbert and P.D. O'Brien, "Using
Types and Inheritance in Object-Oriented Programming," IEEE Software,
Vol. 4, No. 5, September 1987, pp. 71 - 79.

[Harland, 1984]. D.M. Harland, Polymorphic Programming Languages --
Design and Implementation, Halstead Press, New York, New York, 1984.

[Jacky and Kalet, 1987]. J.P. Jacky and I.J. Kalet, "An
Object-Oriented Programming Mechanism for Standard Pascal,"
Communications of the ACM, Vol. 30, No. 9, September 1987, pp. 772 -
776.

[Johnson, 1986]. R.E. Johnson, "Type-Checking Smalltalk," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol.  21,
No. 11, November 1986, pp. 315-321.

[Kahn et al, 1987]. K. Kahn, E. Tribble, M. Miller, and D. Bobrow,
"Vulcan: Logical Concurrent Objects," in Research Directions in
Object-Oriented Programming, B. Shriver and P. Wegner, Editors, The
MIT Press, Cambridge, Massachusetts, 1987, pp. 75 - 112.

[Keene, 1989]. S.E.Keene, Object-Oriented Programming in Common Lisp,
Addison-Wesley, Reading, Massachusetts, 1989.

[Kristensen et al, 1987]. B.B. Kristensen, O.L. Madsen, B.
Moller-Pedersen and K. Nygaard, "The BETA Programming Language," in
Research Directions in Object-Oriented Programming, B. Shriver and P.
Wegner, Editors, The MIT Press, Cambridge, Massachusetts, 1987, pp. 7
- 48.

[Lieberman et al, 1988]. H. Lieberman, L. A. Stein, and D. Unger, "Of
Types and Prototypes: The Treaty of Orlando," OOPSLA '87 Addendum
to the Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 5,
May 1988, pp. 43 - 44.

[Liskov et al, 1977]. B.H. Liskov, A. Snyder, R. Atkinson, and C.
Schaffert, "Abstraction Mechanisms in CLU," Communications of the ACM,
Vol. 20, No. 8, August 1977, pp. 564 - 576.

[Liskov, 1988]. B. Liskov, "Data Abstraction and Hierarchy," OOPSLA
'87 Addendum to the Proceedings, Special Issue of SIGPLAN Notices,
Vol. 23, No. 5, May 1988, pp. 17 - 34.

[Low, 1988]. C. Low, "A Shared Persistent Object Store," ECOOP '88:
Proceedings of the European Conference on Object-Oriented Programming,
Lecture Note on Computer Science, Volume 322, Springer Verlag, New
York, New York, 1988, pp. 390 - 410.

[Merrow and Laursen, 1987]. T. Merrow and J. Laursen, "A Pragmatic
System for Shared Persistent Objects," OOPSLA '87 Conference
Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No. 12,
December 1987, pp. 103 - 110.

[Meyer, 1986]. B. Meyer, "Genericity Versus Inheritance," OOPSLA
Conference Proceedings, (Special Issue of SIGPLAN Notices, Vol. 21,
No. 11, November 1986), Association for Computing Machinery, New York,
New York, 1986, pp. 391 - 405.

[Meyer, 1987]. B. Meyer, "Eiffel: Programming for Reusability and
Extendability," SIGPLAN Notices, Vol. 22, No. 2, February 1987, pp. 85
- 94.

[Milner, 1978]. R. Milner, "A Theory of Type Polymorphism in
Programming," Journal of Computer and System Sciences, Vol. 17, 1978,
pp. 348 - 375.

[Milner, 1984]. R. Milner, "A Proposal for Standard ML," ACM Symposium
on Lisp and Functional Programming, August 1984, pp. 184 - 197.

[Mitchell et al, 1979]. J. Mitchell, W. Maybury, and R. Sweet, Mesa
Language Manual, Technical Report, Xerox PARC, Palo Alto, California,
1979.

[Moon, 1986]. D.A. Moon, "Object-Oriented Programming With Flavors,"
OOPSLA Conference Proceedings, (Special Issue of SIGPLAN Notices, Vol.
21, No. 11, November 1986), Association for Computing Machinery, New
York, New York, 1986, pp. 1 - 8.

[Perez, 1988]. E.P. Perez, "Simulating Inheritance With Ada," Ada
Letters, Vol. 8, No. 5, September-October, 1988, pp. 37 - 46.

[Schaffert et al, 1986]. C. Schaffert, T. Cooper, B. Bullis, M.
Killian, and C. Wilpolt, "An Introduction to Trellis/Owl," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol.  21,
No. 11, November 1986, pp. 9 - 16.

[Simonian and Crone, 1988a]. R. Simonian and M. Crone, "INNOVADA: An
Object-Oriented Ada Environment," Proceedings of the U.S. Army
Information Systems Engineering Command Advanced Technology Office --
Technology Strategies '88 Conference, February 9-12, 1988, The
American Defense Preparedness Association, Washington, D.C., pp. 63 -
74.

[Simonian and Crone, 1988b]. R. Simonian and M. Crone, "InnovAda: True
Object-Oriented Programming In Ada," Journal of Object-Oriented
Programming, Vol. 1, No. 4, November/December 1988, pp. 14 - 21.

[Smith et al, 1987]. R.G. Smith, P.S. Barth, and R.L. Young, "A
Substrate for Object-Oriented Interface Design," in Research
Directions in Object-Oriented Programming, B. Shriver and P. Wegner,
Editors, The MIT Press, Cambridge, Massachusetts, 1987, pp. 253 - 315.

[Snyder, 1986]. A. Snyder, "Encapsulation and Inheritance in
Object-Oriented Programming Languages," OOPSLA '86 Conference
Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11,
November 1986, pp. 38 - 45.

[Stefik and Bobrow, 1985]. M. Stefik and D.G. Bobrow,
"Object-Oriented Programming: Themes and Variations," The AI Magazine,
1985, pp. 40 - 62.

[Stein, 1987]. L.A. Stein, "Delegation Is Inheritance," OOPSLA '87
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No.
12, December 1987, pp. 138 - 146.

[Stroustrup, 1986]. B. Stroustrup, "An Overview of C++," SIGPLAN
Notices, Vol. 21, No. 10, October 1986, pp. 7 - 18.

[Touati, 1987]. H. Touati, "Is Ada an Object-Oriented Programming
Language?," SIGPLAN Notices, Vol. 22, No. 5, May 1987, pp. 23 - 26.

[Unger and Smith, 1987]. D. Ungar and R.B. Smith, "Self: The Power of
Simplicity," OOPSLA '87 Conference Proceedings, Special Issue of
SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 227 - 242.

[Waurzyniak, 1989]. P. Waurzyniak, "Borland Pulls Object Orientation
Into Its Fold," ComputerWorld, Vol. 23, No. 18, May 1, 1989, page 37.

[Wegner, 1983]. P. Wegner, "On the Unification of Data and Program
Abstraction in Ada," Proceedings of the 10th Annual ACM Symposium on
Principles of Programming Languages, 1983, pp. 256 - 264.

[Wegner, 1986]. P. Wegner, "Classification in Object-Oriented
Systems," SIGPLAN Notices, Vol. 21, No. 10, October 1986, pp. 173 -
182.

[Wegner, 1987a]. P. Wegner, "The Object-Oriented Classification
Paradigm," in Research Directions in Object-Oriented Programming, B.
Shriver and P. Wegner, Editors, The MIT Press, Cambridge,
Massachusetts, 1987, pp. 479 - 560.

[Wegner, 1987b]. P. Wegner, "Dimensions of Object-Based Language
Design," OOPSLA '87 Conference Proceedings, Special Issue of
SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 168 - 182.

[Wegner, 1989]. P. Wegner, "Learning the Language," Byte, Vol. 14, No.
3, March 1989, pp. 245 - 253.

[Wirth, 1983]. N. Wirth, Programming In Modula-2, Second Edition,
Springer-Verlag, New York, New York, 1983.

[Wolf, 1989]. W. Wolf, "A Practical Comparison of Two Object-Oriented
Languages," IEEE Software, Vol. 6, No. 5, September 1989, pp. 61 - 68.

[Yonezawa et al, 1986]. A. Yonezawa, J.-P. Briot, and E. Shibayama,
"Object-Oriented Concurrent Programming in ABCL/1," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No.
11, November 1986, pp. 258 - 268.

[Zaniolo, 1984]. C. Zaniolo, "Object-Oriented Programming in Prolog,"
1984 International Symposium on Logic Programming, Atlantic City, New
Jersey, February 1984, IEEE Computer Society Press, Washington, D.C.,
pp. 265 - 270.

