Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!happy.colorado.edu!hsrender
From: hsrender@happy.colorado.edu
Newsgroups: comp.object
Subject: Re: The Emperor Strikes Lethe
Message-ID: <1991Apr8.134519.1@happy.colorado.edu>
Date: 8 Apr 91 19:45:19 GMT
References: <43.UUL1.3#913@acw.UUCP>
Sender: news@colorado.edu (The Daily Planet)
Organization: University of Colorado, Boulder
Lines: 269
Nntp-Posting-Host: happy

In article <43.UUL1.3#913@acw.UUCP>, guthery@acw.UUCP (Scott Guthery) writes:
> It's been about a year since I published "Are the Emperor's New Clothes
> Object Oriented?" in Dr. Dobbs Journal.  In that article I posed nine
> questions that I felt had to be answered in the process of determining if OOP
> was ready to be used in an engineering or product-development setting.
> Here's my assessment of the current answers to these questions based on a
> light reading of the OOP literature since then together with following the
> various newsgroups on the subject.  

First off, let me say that although I think skepticism is a good thing, you
seem to be predisposed to reject OO ideas.  The only way to determine
whether something is really useful in any setting is to use it in that setting.
One of the problems with making any advances in software development in our
country seems to be the overwhelming opposition to any new (or even recycled)
idea or technique.  Your article is an example of this.

Anyway, a couple of observations on your questions:

> 1) Where's the evidence?
> 
> Some is starting to come in.  OOP seems to make writing code a little easier.
> It certainly gives us the opportunity once again to rewrite everything and
> this means job security for programmers.  About every 10 years in programming
> we have to change syntax and OOP is the change for the 90's.  OOP does seem
> to be harder to debug, harder to test, and harder to maintain when the
> maintainers are not the developers.  

OOP is not just a change in syntax, it is an attempt to incorporate support
for things that people do anyway: reuse code, encapsulate implementation,
build concept hierarchies, etc.  Whether it is done well depends on the 
subject and the language/method being considered.  Speaking of evidence, 
where's the evidence that OO programs are harder to debug and test?  In
my own limited experience, I've found Smalltalk code to be easier to test,
debug, and maintain than C code.

> 2) What is an object?
> 
> There seems to be general agreement on what object classes and instances
> ought to be in theory but practice is something else as witness the debate
> over my definition of an object.  There are still a lot of new words being
> invented for old ideas.  An object class is a coding form or an 029 keypunch
> control card and an object instance is a tab card.  And, yes Virginia, tab
> cards did inheritance. (What? You don't remember the 029?)

Maybe it's because I'm a relative youngster (I've only been programming for 10
years) but I don't know what a coding form is, or a 029 control card, or a tab
card.  I started programming on punch cards but left them behind back in '82.
Regardless, the fact that there is ongoing debate on the definition of object
and other terms does nothing to belittle the value of OO thinking.  When all
is said and done, any computation can be encoded in machine language (or for
the theoretically minded, on a Turing machine), but the development of new
abstractions is a result of attempting to come up with more comprehensible
explanations of things people already do/talk about.  In short, if "class"
is more intuitive term than "coding template" for the same thing, then I
think we ought to use "class".

> 3) What's the cost of OOP code reuse?
> 
> We still don't know mainly because we're seeing about the same style and
> level of reuse of OOP code as we do with non-OOP code.  Everybody and his dog
> has done a C++ string class.  After 10 years of Objective-C there are still
> just two Objective-C IC Packs.  We still mostly copy source code, hack and
> go.  Unfortunately, there is still enough slop in the definition of the most
> widely used OO language, C++, that getting one C++ compiler to accept what
> another will pass is a large problem so even classical reuse is harder in OOP
> land.

This is a shuck.  Every language I've ever programmed in (and I quit counting
after 12) has been subject to the whims of compiler vendors.  Even Ada, with
it's much heralded standard, was subsetted extensively back when I was checking
out Ada compilers in '85.   As for the levels of reuse currently employed, just
because we haven't been monstrously successful doesn't mean it's not easier
to do in an OOPL.  I know that the NIH C++ library is widely used, and I hear
that the GNU C++ libraries have been used by many who aren't worried about
the copyleft.  Whether it is easier to do than in a "conventional" PL depends
mostly on the packaging constructs available in the language.  I find modules
and classes easier to reuse than subroutines.  Is this subjective?  Yes.  

> 4) How does one combine object heirarchies?
> 
> One big hierarchy is still the only way to get objects to communicate within
> the rules of the game since the whole point of hidden internal structure is
> to make communication with "outsiders" impossible.  On the other hand, there
> are a growing number of practical work-arounds ... friend objects, neighbor
> objects, significant other objects, passing acquaintance objects, etc.

Either you're not expressing yourself well, or you don't know what you're 
talking about.  One puts things into a class hierarchy to share definition
and implementation details (the coder's point of view) and to denote 
conceptual relationships between kinds of objects (the designer's point 
of view).  No OO language that I know of forces you to put things in the 
same hierarchy just so that they can interact (unless you are thinking of
languages like Smalltalk where every class is descended from class 
Object--this is not a limitation in any way that I know).

BTW, the whole point of hidden internal structure is not the make communication
impossible, just to restrict to a set of monitored paths.  This is the same
principle of putting an interface on a module.  Are you saying that I can't
use a module unless I have knowledge of it's interior?  If so, I'd go look
at the early papers on modular programming.  You seem to be unclear on the
concept.

> 5) How does one tune an OO program?
> 
> Well, the way you tune any other program.  The program structure itself has
> to absorb information about how it is being used.  Since OO programs are
> bigger and slower because so much of the development scaffolding is left in
> the runtime image more of this usage information has to be put into the
> program.  Thus, the complexity of the program increases due to programmer
> laziness.  Of course, since increased complexity means more programmers and
> job security for existing programmers the reward for this laziness is
> continued employment.  Nice scam.

The way you tune a program is by figuring out what it has to do and figuring
out the most efficient way of doing that in the language you are using.  You
are right that this is the same for an OOPL as for a conventional PL.  You
are also right that OO programs may be slower due to the additional stuff
that the translator leaves in the load image.  However, this is true of any
language where the compiler does more than that of a conventional language.
Take a look at the runtime support required of LISP, PROLOG, SNOBOL, Icon
and a few other unconventional languages. Each one of these is easier to
program in than, say, FORTRAN, because each has features designed to make
the programmer's job easier by making the translator do more.  Does this
make the load image bigger?  You betcha.  Does it make the program more
complex?  Not from the programmer's viewpoint.  Does it make it harder to
tune?  You betcha, for the same reason that it is easier to tune assembler
than it is to tune FORTRAN code.

> 6) How does one manage an OOP development team?
> 
> Very carefully and very closely.  Since adding new code to an OO system can
> change the behavior of (i.e. break) old code every programmer essentially
> needs to know the whole system in order to add code to it.  This is
> particularly the case if polymorphism is used since each programmer has to
> understand and build on the puns being perpetrated by all the others.

Another shuck.  A programmer is only likely to "break" an OO system if s/he
redefines existing code.  This is true for conventional systems as well.
Changing an instance method (or member function) is just as likely to
break a system as changing a subroutine in a FORTRAN library.  The only
major difference is that the method may be inherited by other classes,
so the change may be automatically propagated to other parts of the system.
This is a problem, but it is also the reason people are investigating ways
to track/restrict inheritance paths.  In general, the configuration management
problems are the same.  As for polymorphism being particularly nasty, this is
only true insofar as polymorphic code is likely to be widely used, and any
error introduced into that code is thus like to be widely propagated.  However,
because the error need only be corrected in only one place, the fix can also
be widely propagated.  So is this bad?

> 7) Do OO programs coexist?
> 
> Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't
> inherit from Smalltalk objects.  Each OO technology is a programing bunker
> world unto itself.  This is true in practice only, of course.  In theory the
> world is always exactly as we wish it to be.

Since when is this a unique problem of OO code?  Linking code written in 
different languages has always been troublesome.  Because of the greater
runtime support of most OOPLs the problem may become greater, but I don't
think of it as inherent to the OO paradigm.  

> 8) What are the consequences of persistent state?
> 
> Mostly it makes testing a lot harder and a lot more unreliable since every
> possible combination of retained state must be checked.  But then, heck, an
> object-oriented program is so clean and clear that we don't really need to
> test it so who cares how hard it is, right?  Have you heard of the Parnas
> test?

Wrong.  Given that the methods of an object control access to the variables,
one need only test methods to determine if there is an invalid combination.
Although this is difficult, this is no more difficult than testing a FORTRAN
program that has several global variables and subroutines for manipulating
their values.  In fact, it is considerably less difficult (in my opinion) 
in an OO because access is limited absolutely to the methods associated with
the containing class.  (Actually, this depends on the language and the
program, since some languages allow instance variables to be accessed like
regular record fields).


> 9) Can you get the development system out of the production system?
> 
> Nope.  The uniform response of the OO community to the runtime overhead
> problem is "buy a bigger machine" or, in translation, "the hardware guys will
> have to save our butts again".  It seems to come as a shock to OO programmers
> that the folks buying these machines expect to be the beneficiaries of the
> hardware curve not the programmers ... afterall it's their money.  People who
> buy cmoputer to solve their problems don't expect the curve to be eaten up
> (and then some!) by having to constantly slog through leftover
> development-time scaffolding.  (Do you know what happens to surgeons who
> leave the tools of their trade inside their patients?)  OOP imposes a runtime
> tax that end-users aren't interested in paying even with weak excuse that the
> tax pays for more frequent updates since it makes maintenance easier.
> End-users don't want more frequent updates; they want it right in the first
> place.

This is a semi-valid point.  OO langs do require greater runtime support.
For this reason it makes more sense to use them during prototyping when
ease of coding outweighs performance.  People are trying to reduce the 
runtime overhead of OOPLs like Smalltalk, but I have doubts that they will
make a Smalltalk program as fast as an equivalent program in C (although 
I have had people tell me otherwise).  Still, if the performance loss is
small enough, coding ease (and associated decreases in the program under-
standing phase of maintenance) may make it more cost effective to use a 
OOPL rather than a language like C or FORTRAN.

> The OO community will be forced to discover that software consumers won't pay
> development-time taxes at runtime the same way the Lisp community did.  If
> you write your product in some OO language, I'll come out with a competing
> product in written C or maybe even assembler, give all those cycles back to
> the customer, and whip you in the marketplace.  I might thank you for
> defining the product and opening the market which I understand you did by
> using OO technology.  But a thank you and a cloud of dust is all you'll get.

Again, the use of OOPLs for production code will depend on the improvement
in runtime performance.  This is nothing new, as the same thing has been
true of LISP.  However, LISP is still around (after 30-odd years), so if you
think this shortcoming of OOPLs will doom them then you are misleading 
yourself.

> 
> In closing, I note that a non-upward compatible version of the most popular
> OO language, C++, is due out "real soon now".  After 11 years of trying C++
> still doesn't have a stable semantics.  This, more than anything else,
> convinces me that OOP still isn't ready for production use ... unless, of
> course, your boss still thinks paying her programmers for constantly changing
> the syntax of her code is progress.  

It may have been 11 years since C++ first began to be developed, but its
only been 5-6 years since it began to be used much outside of Bell Labs
(at least that I know).  This is a fairly short period of time, much shorter
than the span of time it normally takes for a language to become widely used
in industry.  The fact that it is still evolving is nothing new, since 
FORTRAN is still evolving.  Does this mean it will not be used?  Unlikely,
for the same reason FORTRAN and other evolving languages have continued to
be used despite variant implementations and changing standards.

> There is very little really new in OOP.  As I indicated above, classes,
> instances, and inheritance go back to tab card decks of the 1940's.  Lexical
> scoping was used in Algol in the 1950's.  Polymorphism is found in Fortran 0.
> Even decomposition by type, which Piercarlo Grandi says is the basic idea of
> OO, can be found in the programming language, database, and graphics
> literature of the 1960's. 
> 
> The question we really have to ask ourselves is why are we constantly
> reinventing the wheel?  Why do we imagine that making up new names for old
> problems is progress?  Why don't we get tired of reading the same dreary
> articles and going to the same windy conferences?  Why is the collective
> memory of applied computer science so short?  Only when we can answer this
> question will programming start to make some real progress.

Although nothing in OOPLs is radically new, the combination of these 
features in a coherent fashion is.  I've programmed in a number of 
languages, and all of them are unique in some way, even if it is merely
syntactic.  Yes, there are common constructs and ideas, and yes, there
is a lot of reinventing going on, but it is all due to a quest for the
"perfect" programming language.  Most "new" things are merely 
new arrangements or combinations of existing ideas, expressed in a
better (one hopes) fashion.  Programming languages, like natural
languages, evolve due to changes in their user groups.  To believe
that this is a problem is to say that, at any time, what we have is
good enough.  Although this may be true, it is not something I
think you will ever demonstrate to many people.


hal.
univ. of colorado at colorado springs
render@zeppo.colorado.edu