Xref: utzoo comp.object:467 comp.lang.c++:5613
Path: utzoo!censor!dybbuk!yunexus!ists!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!sunybcs!sbcs!bnlux0!drs
From: drs@bnlux0.bnl.gov (David R. Stampf)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <1562@bnlux0.bnl.gov>
Date: 21 Nov 89 14:09:32 GMT
References: <2664@bingvaxu.cc.binghamton.edu>
Reply-To: drs@bnlux0.UUCP (David R. Stampf)
Organization: Brookhaven National Lab., Upton, N.Y.
Lines: 87

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

	Stop reading arguments and try some OOP programming!  Then read
the arguments and make up your own mind ;-)
	
>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.  ...

	I'm glad he stripped the jargon.  Too bad in removing the jargon
he left off inheritance, polymorphism and encapsulation - which are central
to an OOP approach to problem solving.
	
>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". 
>

	It's important to separate objects (data + methods) from the
rest of OOP.  Fortran had multiple entry points (blech!) but didn't have
static data (i.e. persistent state) unless you think that global (common)
data qualifies.  You might want to read Peter Wegner's "Dimensions of
Object-based Language Design" in OOPSLA '87 proceedings, where he
distinguishes between object-based and class-based and object-oriented
languages.

	A real problem is that languages like Fortran do not map well onto
a total OOP approach to problem solving, and partial comparisons and
implementations are sadly lacking.

>... " 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 was far ahead of its time - hardware and software wise.
Condemning OOP because of the 432 is like condemning aviation because
DaVinci's helicopter wouldn't fly.  If the 432 were being designed today
with our accumulated knowledge of design of really big and complex ICs,
it would have a far better chance of succeeding.

	OOP provides a view of modeling that does not necessarily match 
the von Neuman view of computing machinery.  But then, all languages are 
compromises of the problem set and the target hardware.  If your sole
measurement of success is execution efficiency on a particular machine,
then use an assembly language - but then, what can you do while waiting
for the user to hit return?

	Basic and more recently Hypercard have succeeding more due to
their accessibilty to programmers (and users!) than to their run time 
efficiency.

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

	Anything new runs counter to prevailing practice and experience by
definition.  We owe it to ourselves to investigate *new* approaches to 
problem solving.  The resurging interest in OOP seems to be coming at
at time when machines are powerful enough to support such concepts *and*
our software technology is also growing.  (Compare the initial release
of Smalltalk on the Mac from Apple to Digitalk as an example.  It's hard
to believe the performance differences between the two!)

	Finally, prevailing practice and experience are not necessarily
the same thing as prevailing *wisdom*, in fact, the growth in the number
of articles on OOP indicate that the wisdom is growing.  If this wisdom
shows that OOP is good, practice and experience will follow.  If not,
it then we still will have learned something.  Either case, we win.

	It is kind of scary to think that the Fortran model - one of our
first tries at programming - was the right way ;-).

	< dave stampf