Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!mcnc!nowhere!rick
From: rick@cua.cary.ibm.com (Rick DeNatale)
Newsgroups: comp.object
Subject: Re: blip [Re: Dynamic typing -- To Have and Have Not ...]
Message-ID: <1991Apr11.174144.10274@cua.cary.ibm.com>
Date: 11 Apr 91 17:41:44 GMT
References: <14160@life.ai.mit.edu> <1991Mar25.201620.5839@cua.cary.ibm.com> <879@puck.mrcu>
Sender: rick@cua.cary.ibm.com (Rick DeNatale)
Reply-To: rick@cua.cary.ibm.com.UUCP (Rick DeNatale)
Organization: cua
Lines: 49

In article <879@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes:
>
>I assume that this is a sideswipe at Eiffel.  It is true that the
>current implementation has this problem (amongst others).  However ISE
>have promised that their implementation of Eiffel 3 will fix this
>problem.  I assume other vendors will be following the same policy
>(anyone from Sig Computer want to comment?)  Basically you are
>criticising the language by critcising the implementation.  This is
>not a good argument.

Au contraire mon ami, I was not swiping at Eiffel, and particularly not 
at its implementation of which I have no direct experience.  I was criticizing
the practicality of currently implementable compile time type systems, that
all seem to require various loopholes, or at least the rearrangement of 
implementation hierarchies to deal with new components added to a system.

My idea of the power of object oriented programming is to get away from
the necessity of coming up with a new consistent set of axioms whenever I
want to maintain/evolve my software, and to do this with a set of independently
developed components.  Type hierarchies tied to class hierarchies seem to
force this type of re-analysis which seems antithetical to reuse.  Reuse
means keeping as much the same as possible, whilst some things are changing.
I want to avoid reimplementation wherever possible, and the arguments of
the strong typists always seem to take the form ... "well in this case
your hierarchy should look like this ... and this just looks like too much
reimplementation to me.

>On the other hand I am interested in the assertion that type errors
>are rare in Smalltalk development.  Does anyone have any statistics to
>back this up?  I think this discussion could probably do with an
>injection of fact, lest it degenerate into a language flame war.
>
I've talked about this with a number of other experienced Smalltalk 
programmers and there is a remarkable degree of concensus, at least 90%
of the "doesNotUnderstand" errors come from sending a message to nil, the
UndefinedObject.  In other words they are state errors (uninitialized 
variables).  The others seem to surface right away after I do a compile, test
cycle.  In a strongly typed language this would be a series of compiles to
get the type errors out.

I've demoed a variety of Smalltalk applications written by myself and others,
and I really can't recall ever being embarrassed by a "doesNotUnderstand"
error regardless of how high level the management I've showed it to.  In
fact when I'm pressed to generate such an error intentionally to demonstrate
the nice debugger, I often have a hard time figuring out how to gen up a 
nice little error!

Rick DeNatale
Of course my opinion is my own, who else would want it?