Xref: utzoo comp.object:488 comp.lang.c++:5645
Path: utzoo!attcan!uunet!mitel!sce!ulysses!garym
From: garym@ulysses.UUCP (Gary Murphy)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <7539@ulysses.UUCP>
Date: 22 Nov 89 14:09:40 GMT
References: <2664@bingvaxu.cc.binghamton.edu>
Reply-To: garym@cognos.UUCP (Gary Murphy)
Followup-To: comp.object
Organization: Cognos Inc., Ottawa, Canada
Lines: 43

I had the pleasure of reading a pre-release of Scott's paper, which
I found somewhat humourous, and somewhat disturbing.  While he has
some good points, there is little in what he says that does not apply
to all programming and especially to any new paradigm.  I don't want
to go in to this at length, but I will say that issues such as non-
standard object representation, the requirement for development tools
and the supposed counter-evolutionary aspects are greatly overstated
and were as true for the early C or Pascal implementations as they
are for the present state of OOP.  Does anyone know of two prologs
which use the internal structures or even the same syntax?  Can you
say "proprietary technology"?

I haven't seen the DDJ print, but my advance notes include a summary
of "Twenty-Five Reasons" in 9 sections.  Under "Theory", all of the
points apply equally to all programs using structures and pointers,
"Development" makes one valid point of there being a lack of proper
tools (Scott thinks toolmaking is bad, fortunately he doesn't build
ships), with 7 other points which apply to all development, "Debugging"
give 5 non-points where the fifth merely complains that the old tools
are not applicable, "Maintenance" likewise applies in all 7 points to
many programming systems, "Persistent State" shows three points common
in any program which uses trees & graphs, and the remaining sections
likewise jump on general problems as if they were peculiar to OOP.

This is not to praise OOP or to can Scott's well-said article, it's
just that I wish he'd stayed with 9 or ten good points rather than
bloating otherwise valid arguments with non-issues.  For instance 
(oops! can I say 'instance'?), he complains that OOP requires retooling
the development organization without regard for the retooling we did
when we shifted from patch-cords to punch-cards to consoles or from
programming in Hex to Fortran and later to C, Prolog or whatever.  He
adds that he doesn't want YAPL (yet another programming language).

I think we all should read this.  Everyone here found it at least
amusing.  He has some very valid points which should be addressed by
any OOP plans and clearly dispels some of the marketting hype
surrounding OOP.  I'd caution anyone not to rely on this paper when
deciding for or against OOP, but to instead use it as a guide for
which questions to ask.-- 
Gary Murphy                   decvax!utzoo!dciem!nrcaer!cognos!garym
                              (garym%cognos.uucp@uunet.uu.net)
(613) 738-1338 x5537          Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3
"There are many things which do not concern the process" - Joan of Arc