Xref: utzoo comp.object:457 comp.lang.c++:5603
Path: utzoo!attcan!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <1989Nov22.002133.7341@odi.com>
Date: 22 Nov 89 00:21:33 GMT
References: <2664@bingvaxu.cc.binghamton.edu>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 56
In-Reply-To: cjoslyn@bingvaxu.cc.binghamton.edu's message of 21 Nov 89 01:43:34 GMT

In article <2664@bingvaxu.cc.binghamton.edu> cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes:

   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.  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". 

He misses the point entirely.  Fortran II and Algol are sort of like
object-oriented programming where you can only have one instance of
any given class.  This makes it pretty useless.

Of course, you can do object-oriented programming in any language
whatsoever.  The X Window System is written in C and uses
object-oriented programming with inheritance.  The language (C) does
not provide *support* for this style, so it ends up being verbose and
clumsy, but it does work.  Another interesting example is Sun's RPC,
the source code of which is free (you can get it from uunet).  It uses
very simple object-oriented programming in C; no inheritance, but you
can clearly see that it's OOP with instances and with the equivalent
of virtual functions.  They again have to do all the work by hand, but
they follow consistent stylistic guidelines so it doesn't mess the
code up too much.  If Sun RPC were not written in that style, it would
be a much worse piece of software.  They use OOP in order to allow
extensibility: several alternative network protocols, several
alternative authentication methods, several kinds of XDR stream.

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

This, of course, depends a lot on how much runtime efficiency is being
"sacrificed".  The overhead in C++ is very small; this has been discussed
to death on this newsgroup.

	      to programmer's convenience, this emphasis on the ease with
   which code is generated to the exclusion of the quality, usability, and
   maintainability of that code, 

That's really beyond the pale.  OOP, in my experience, properly used,
greatly increases quality, usability and maintainability.

				 is not found in any production programming
   environment with which I am familiar.  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?"

What an illogical argument.  Some people at Intel figured out how to
do something very slowly, and they used hardware to do it,
therefore... Anyone who believes this has his brain turned off.

To say that this piece is poorly reasoned is to be too kind.

Dan Weinreb		Object Design		dlw@odi.com