Xref: utzoo comp.object:459 comp.lang.c++:5605
Path: utzoo!attcan!uunet!zephyr.ens.tek.com!orca!demiurge!brucec
From: brucec@demiurge.WV.TEK.COM (Bruce Cohen;685-2439;61-028)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <5427@orca.WV.TEK.COM>
Date: 22 Nov 89 01:40:01 GMT
References: <2664@bingvaxu.cc.binghamton.edu>
Sender: nobody@orca.WV.TEK.COM
Reply-To: brucec@demiurge.WV.TEK.COM (Bruce Cohen)
Followup-To: comp.object
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 121

OK, I'll take the bull by the horns here:
In article <2664@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes:
>
>I'm not an OOP programmer, but I read a real convincing argument in the
>latest Doctor Dobb's Journal #158, "Are the Emporer's New Clothes Object
>Oriented?", pp. 80-86 by Scott Guthrey.  
>
>He says a lot of things, but one quote: "Stripped of its fancy jargon,
>an object is a lexically-scoped subroutine with multiple mutiple entry
>points and persistent state.

This is not a correct definition of OOP for the following reasons:
    1) It completely ignores the issues of inheritance, data abstraction,
and data-hiding.

    2) Objects aren't necessarily lexically-scoped (look at ST-80 blocks,
for instance).

    3) (Maybe a bit picky as to terminology, but ...) an object really
can't be compared to a single subroutine, or even a single coroutine.  It
might be better compared to a multi-threaded server, which provides
services (one per method) to access and modify a persistent state.

>  OOP has been around since subroutines were
>invented in the 1940s.  Objects were fully supported in the early
>programming languages AED-0, Algol, and Fortran II.  OOP was, however,
>regarded as bad programming style by Fortran aficionados". 

Again, not true if you look at the issues in 1) above.

>
>And more: "...the programmer is invited to pass the cost of expedience
>onto the user of the system.  This wholesale sacrificing of runtime
>efficiency to programmer's convenience,

Ask a veteran C++ programmer about this "wholesale sacrificing".  I have
programmed in OO Lisp, Smalltalk, and C++ (I've been primarily a
systems-level C programmer for the last six years, and before that I did a
lot of assembly language).  I don't feel that I have sacrificed performance
to anything; in some cases I doubt that it would have been at all possible
to code the sorts of things I have done in C++ in C and get more than a few
percent improvement, and doing so would have made the projects I was
working on impractical (see my next comment).

> this emphasis on the ease with
>which code is generated to the exclusion of the quality, usability, and
>maintainability of that code, is not found in any production programming
>environment with which I am familiar.

Then it should be, because all three of those qualities are intimately
intertwined with ease of programming.  Using OOP has allowed me to build
systems which are much MORE robust against changes, and much easier to
modify and enhance than would have been practical in C without much more
time and energy, which would not have been allowed on the projects.
Certainly, the data encapsulation alone is a major factor in increased
quality.  Granted, that's not unique to OOP, but the behavior encapsulation
(inheritance and overriding of methods) is unique to OOP, and it is an
additional factor in improving quality.

>  Let's not forget the Intel
>432...which was OOP in silicon, and it failed because it was just too
>slow.  If we couldn't make OOP efficient in hardware, why do we think we
>can make it efficient when we emulate it in software?"

Yes, let's not forget it, but let's remember why it failed (I was in
another division at Intel at the time, and had reasonably good visibility
into the 432 project; in fact I had a prototype 432 board running in my
Intel blue box!).  The problem wasn't OOP, it was in the implementation of
the silicon, and the way the software was layered on it.  For instance, in
the Rev. 3 chip set, simply turning the access control data structures
upside down and addressing them off the object data pointers speeded almost
everything up by a factor of two.  Also, because they couldn't fit as many
gates on a chip as they had originally planned, the processor had to be
put in two chips, with a 16-bit bus in between, which slowed things up
some.  And so on.  By the time they had the project far enough along to
start doing even the simplest optimizations, Marketing had already
published benchmarks which said that the 432 couldn't beat a lame dog into the
bath water, and the resultant public bad-mouthing killed any chance of
selling to anyone.

>And the conclusion: "OOP runs counter to much prevailing programming
>practice and experience: in allocating and controlling software costs,
>in modularity, in persistent state, in reuse, in interoperability, and
>in the separation of data and program.

I can't resist commenting on this remark about the separation of data and
program.  It shows to me that the author of the article doesn't understand
OOP implementation at all.  Certainly there are some OOPLs which allow you
to execute data (that's what LISP does for a living), but in the normal
course of events (i.e., if you don't twist things around to make it happen
yourself), neither Smalltalk nor C++ will do so.  An object's state is
data, the methods which operate on it are code, and the two are separate.
You might choose which method to use on a given bit of state, or which
state to operate on, by looking at which or which kind of object you have,
but that's just normal programming practice.  If you have ever coded a
finite-state machine you have built what amounts to an instance of an
object.  Send it an input (invoke a method) and it will change its state
and (maybe) provide some output.

>  Running counter to the
>prevailing wisdom does not, of course, automatically make an innovation
>suspect but neither does it automatically recommend it.  To date, in my
>opinion, advocates of OOP have not provided us with either the
>qualitative arguments or the quantitative evidence we need to discard
>the lessons painfully learned during the first 40 years of programming". 

On the contrary, OOP builds on lessons such as data abstraction.

>
>Any comments?
>

The rhetoric is very dramatic, but hardly compelling.  I would be swayed
more if I believed that the author knew more about the subject being thrashed.

"Small men in padded bras don't look the same falling from high places."
	- R.A. MacAvoy, "The Third Eagle"
Bruce Cohen
brucec@orca.wv.tek.com
Interactive Technologies Division, Tektronix, Inc.
M/S 61-028, P.O. Box 1000, Wilsonville, OR  97070