Path: utzoo!attcan!uunet!aplcen!samsung!usc!cs.utexas.edu!rutgers!njin!princeton!phoenix!markv
From: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Newsgroups: comp.object
Subject: Re: Guthery slams OOP in latest DDJ
Message-ID: <11676@phoenix.Princeton.EDU>
Date: 22 Nov 89 02:06:39 GMT
References: <2664@bingvaxu.cc.binghamton.edu> <1989Nov22.002133.7341@odi.com>
Reply-To: markv@phoenix.Princeton.EDU (Mark T Vandewettering)
Organization: Princeton University, NJ
Lines: 46


Gosh, I realized there was stilly more to bash Guthry for:

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

Nope.  Sorry.  Uh uh.  Wrong.  

I might actually agree with the definition of objects.  If you chose to
implement an object in a language, say Scheme, one obvious
implementation is as a closure with a message dispatcher (multiple entry
points) and persistant state maintained inside the closure.

What about inheritance?  Instantiation of multiple instances of a class?
There is more to objects than just lexical closures.  

And of couse, the languages he dredges up had absolutely no support for
object oriented programming.  Sure, you might be able to fake something
that vaguely resembled an object, but it is obvious that you are faking
it.

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

I haven't forgotten it: has Mr. Guthry ever read anything other than
glossy BS about it?

I hate this argument.  First of all, the 432 had many other goals
besides being an effective object oriented processor.  It was supposed
to be easily entendible to multiprocessor configurations (requiring no
code changes), data protection, a sophisticated fault mechanism, with
recovery.  It had many noble goals.  It succeeded at alot of them.  
It was a huge chip.  It was slow.  It had no cache.  It was a commercial
failure.  So what?  It succeeded at several of its goals.

But just building something "in hardware" doesn't make it fast.  It
takes an appropriate design, both for the chip, compilers and programs.
That technology is improving.

Mark VandeWettering