Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!steve
From: steve@cs.qmw.ac.uk (Steve Cook)
Newsgroups: comp.object
Subject: The Emperor Strikes Back
Message-ID: <3351@sequent.cs.qmw.ac.uk>
Date: 15 Feb 91 20:50:37 GMT
Reply-To: steve@cs.qmw.ac.uk (Steve Cook)
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 215
Expires:
References:
Sender:
Followup-To:
Keywords:


A while ago, there was an article by Scott Guthery in Dr Dobbs
Journal called "Are The Emperor's New Clothes Object-Oriented?"
This article was reprinted in the February edition of
Microsystems Design in the UK.  I wrote a reply article, and I
thought the net might have some fun with it.  Here it is.


The Emperor Strikes Back
Steve Cook, Object Designers Ltd

Introduction

This is a reply to Scott Guthery's article 'Are The Emperor's New Clothes
Object-Oriented?', the colourful hatchet-job on object-oriented programming
published elsewhere in this issue.  Guthery wields some punchy phrases, and
hacks out a biting metaphor or two.  If you didn't know better, you might
think he knows what he's talking about.  The trouble is, he mostly doesn't.
It's perfectly true that there is lots of hype about object-orientedness.
Today, every peddler of a software panacea must claim it's object-oriented.
There have been software panaceas for as long as there has been money to be
made from people who'll buy them.  Object-oriented is just the latest in a
long and dishonourable line; its predecessors were Artificial Intelligence
and CASE, and I'm sure you can name many others.
At the same time, there have been honest efforts to develop our
understanding of software, and sometimes these have led to genuine
improvements.  From my experience, I believe that within the collection of
techniques often called object-oriented technology there are some important
breakthroughs which need to be developed and exploited.
Guthery questions object-oriented programming, and attempts to demolish the
claims made by its proponents.   There is a grain of truth in some of his
points, but in every clear statement of fact in his article, he is just
plain wrong.
Let's look at his first claim: 'The biggest OOP projects undertaken to date
seem to be the OOP development systems'.  Off the top of my head, I can cite
the following counter-examples.   The Apple Macintosh operating system was
first developed for the Apple Lisa in Clascal, an object-oriented extension
to Pascal.  The NeXT operating system is fully object-oriented.   In the
area of applications there are large medical systems by Hewlett Packard,
spacecraft activity planning at the Jet Propulsion Laboratory, and the
Manufacturing Activity Control System at McDonnell Douglas.  Many CASE
tools, including Arthur Anderson's Foundation and Cadre's Teamwork are built
using object-oriented languages.  Every workstation and PC window manager
uses object-oriented principles, even if they don't use an object-oriented
language.  There are hundreds more examples.

What is an object?

According to Guthery, 'stripped of its fancy jargon, an object is a
lexically-scoped subroutine with multiple entry points and persistent
state'.  If that's not fancy jargon, I don't know what is; but let's have a
closer look at it.
The killer is 'lexically-scoped'.  It's a while since I heard the phrase, so
I checked it in Abelson and Sussman's book, 'Structure and Interpretation of
Computer Programs'.  According to them, lexical scoping means that free
variables in procedures are statically bound to variables in
textually-enclosing procedures, just like free variables in nested
procedures in Pascal.  But the most fundamental idea of object-oriented
programming is dynamic  binding of operation names to operations at
run-time.  Lexical scoping has nothing whatever to do with objects.  Can
somebody who's failed so completely to grasp the basic idea be trusted to
criticise the whole technology?
The argument about the definition of C++ taking 9 years is disingenuous.
I'm not going to defend C++.  You can do object-oriented programming in it,
as well as other kinds (including the sort that Guthery presumably wants us
all to do).  It has good and bad points, and this isn't the place to discuss
them.  It's true to say that version 1 was released to the world in 1985,
and a slightly incompatible version 2 in 1989, but how this can be used as
an argument against object-oriented programming in general beats me.

OOP Code Reuse

Guthery's diatribe about code re-use completely overlooks the distinction
between compile-time and run-time.  Object-oriented hierarchies are not
object hierarchies, they are class hierarchies.  'Clipping the objects out
of the hierarchy' simply doesn't make sense, so no wonder you can't do it.
So what's the point?  Because there is a grain of truth in what he says, and
it has to do with linking technology.  The bottom line is his claim that
systems will be bigger and, therefore, slower.   But run-time system size
actually depends on what the linker includes in the executable file.  In C++
for example, with proper library archiving, what is linked is the transitive
closure of what is referenced, exactly as with C.
Let's be clear, because this is important.  It is false  that
object-oriented programming requires that the entire hierarchy gets linked
into your run-time.  It's also true  that many object-oriented programming
systems do this.  That is a property of the implementation of those systems,
not  a fundamental property of object-oriented programming.

Combining Object Hierarchies

Well, class hierarchies, actually.  Can objects from one language
communicate with those in another? The answer, contradicting what Guthery
says, is yes - using exactly the same technology as you would use at any
other time, with normal subroutine linkages.
'You can't send arguments from one C++ hierarchy to another'.  On the face
of it, this is a meaningless statement.  Neither C++, nor any other
object-oriented programming language, define any concept called 'sending
arguments to hierarchies'.   Let's re-interpret this statement as 'you can't
call functions defined in one hierarchy from another'.  You can.  Let's try
another interpretation: 'you can't pass parameters defined in one hierarchy
to a function defined in another'.  You can do that too.  Guthery's up a gum
tree with this one.
'Object-oriented programming makes integration much more difficult'.  On the
contrary, many people think that objects are exactly the technology that's
needed to make integration easier.  The Object Management Group, with a
hundred members including almost all of the major corporate computer
vendors, has been established on exactly this premise.  Are they really all
mesmerised by the Emperor's Clothes?  It's worth noting that they have
started out from a piece of existing technology, namely HP's New Wave
product, which gives integration between PC applications at a level not
achieved by any other technology to date.  Now I'll admit that New Wave may
not be such a great commercial success at present, but nobody's claiming
that it is technically flawed.

Tuning an object-oriented program

I've had some experience of this, and what Guthery says is piffle.  You tune
an object-oriented program by finding and optimising the bottlenecks, just
like you always did.  Whether you need to drop into C, assembler, microcode,
or send your computation off to a Cray to do it quickly enough, there is
absolutely no problem, and lots of systems do it.
The overhead of 'running around the hierarchy', as Guthery calls it, must
mean the overhead of resolving method lookup in a dynamically-typed language
like Smalltalk.   Now it's absolutely true that Smalltalk-like languages
have a run-time overhead of up to 500%, as compared with comparable
algorithms written in optimised C.  Nobody's hiding this.  But how this
overhead amounts to 'the exclusion of quality, usability and
maintainability' defeats me - as far as I'm concerned, after 7 years of
Smalltalk programming experience, the very reason for sacrificing
performance is to achieve greater quality, usability and maintainability.

Managing a Team

This is the part of Guthery's article which contains the biggest grain of
truth.  It's true that managing a development in the context of hierarchies
requires different techniques, and several companies have indeed come
unstuck by adopting object-orientation.  My own reaction to these failures
is to make an argument for different management techniques, and more
particularly, better tools, to get the benefits of object-orientation in
teams.  This is an area of the technology where more work is definitely
needed.
The sideswipe about debugging is grossly misleading.  Yes, C++ can be hard
to debug, but this is because of features of the language which have nothing
to do with object-orientation.  The debugging environment for Smalltalk is
second to none, and makes bugs remarkably simple to find.

Can OO languages co-exist

At the level of subroutines, any object-oriented language can call any
other, with the same practical restrictions as any other language
technology.  There is a commercial Objective-C product with a Fortran
interface (NeXT) and an object-oriented Lisp product with C and Fortran
interfaces (Symbolics).
It's true that it is not normally possible for a class in one language to
inherit from a class in another (although the NeXT system does allow this up
to a point).  This is because of a lack of agreement about the semantics of
inheritance.  There is plenty of research about this, and no doubt there
will be a solution in the future.  Is an intelligent reaction to this
difficulty simply to ignore the whole technology?  I'll bet the Japanese
don't think so.

Consequences of Persistent State

It seems as if what Scott Guthery means by persistent state is what most
people mean by data abstraction.   If he thinks that data abstraction is a
semantic minefield to be avoided, he's missed out on the last 20 years of
programming methodology.

Removing the Development System

In this section, Guthery shows he doesn't know the difference between
'object-oriented' and 'interpreted'.  Does he really think C++, Eiffel and
Objective-C have interpreted virtual machine technology?  They don't.  Does
he think there are no compiled LISPs?  There are.  And it's wrong to suggest
that the runtime cost of object-oriented programming can't be estimated.
The time costs are well-known, and the space costs depend in a measurable
way upon compilation and linking technology.

Conclusion

With any technology it's possible to take the union of the problems of each
representative of the technology and present them as problems of the
technology as a whole.  This is just as dishonest as doing the same with the
technology's benefits, as the hype-merchants and panacea-peddlers do.
Guthery writes vigorously, but mostly doesn't know what he's talking about.
When he does, he adjusts his targets to suit his assaults: so when he's
attacking performance, he attacks virtual machines, and when he's attacking
debugging and language complexity, he attacks C++.
Object-oriented programming technology is still immature.  It has benefits,
and costs.  It is important, as Guthery says, to gather the evidence
carefully before we make claims.  He says there's been 'absolutely no
evidence gathered or experiments performed to validate the claims made for
object-oriented programming'.  Again, he's wrong.  He should read a pair of
papers in Journal of Object-Oriented Programming, Vol 3 No. 1 and Vol 3 No.
3, by Dennis Moreau and Wayne Dominick of the University of Southwestern
Louisiana, describing research carried out for NASA.   They carefully set up
a framework for evaluating programming methodologies, carry out experiments,
and measure the results, which show that object-oriented programming is
around twice as productive as conventional development.  They say 'as a
direct result of the success of this research, the USL NASA project has, as
of 1987, made a major commitment to object-oriented systems technology as
the primary software development and evaluation foundation for all future
workstation components of the USL NASA Project.'
Simply put, Scott Guthery hasn't done his homework.



-- 

Steve Cook                   steve@cs.qmw.ac.uk
Object Designers Ltd
Glebe House                  Telephone 0279 755396
Great Hallingbury
Bishops Stortford
Herts CM22 7TY


Brought to you by Super Global Mega Corp .com