Xref: utzoo comp.object:503 comp.lang.c++:5670
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!rochester!rit!cci632!tvf
From: tvf@cci632.UUCP (Tom Frauenhofer)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <32016@cci632.UUCP>
Date: 27 Nov 89 16:17:29 GMT
References: <2664@bingvaxu.cc.binghamton.edu>
Reply-To: tvf@ccird7.UUCP (Tom Frauenhofer)
Followup-To: comp.object
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 59

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

Personally, I regard Fortran programming as bad style myself ( :-) ).

Seriously, what a load of ____!  This is an apples and oranges argument.  Of
course OOP is bad Fortran style - Fortran isn't an OOP.  So what?  I don't
see a point here.

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

	Programming convenience != sacrificing runtine efficiency.
	Ease of maintenace != sacrificing runtime efficiency.

Should we sacrifice programming convenience and ease of maintenance for
improved runtime performance?  I want them all, and most serious software
developers do, too.  Any tradeoffs are made on a case-by-case basis.  OOP is
a tool.

Many people can write efficient, maintainable code in a "convenient to use"
OOP.  I know that I am capable of writing inefficient, unmaintainable code
in a "less-than convenient" language like C and Fortran.  It's how you use
the tool as much as it is what the tools give you.

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

The 432 is not slow because it is "OOP in silicon."  It was slow partly
because of its Hydra-based capability mechanisms (I said partly.  There may
have been other reasons as well).

Don't forget that the 432 predates a lot of the current research in OOP.

	Slow performace of one example != OOP is slow.

Sorry for clogging this group with my ramblings.  I've made commentaries on
this (and other) groups in the past, but at least a network like this allows
dialog between the author and the readers.  Sure, DDJ has a letters page,
but who knows if they'll publish letters against this article, or if they do
they might let the author give a reply like "Here are these idiot OO people
proving my point..."  along with further nonsense.  Grrr!

Thomas V. Frauenhofer	...!rutgers!rochester!cci632!ccird7!tvf
*or* ...!rochester!kodak!swamps!frau!tvf *or* ...!attctc!swamps!frau!tvf
"Had coffee with Melnick today.  He talked to me about his idea of having all
government officials dress like hens." - Woody Allen


Brought to you by Super Global Mega Corp .com