Xref: utzoo comp.object:3381 comp.lang.misc:7635
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object,comp.lang.misc
Subject: Re: Run-time Type Errors in Smalltalk
Message-ID: <1991Apr28.022234.287@odi.com>
Date: 28 Apr 91 02:22:34 GMT
References: <3865@ssc-bee.ssc-vax.UUCP> <530@eiffel.UUCP>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 33
In-Reply-To: bertrand@eiffel.UUCP's message of 19 Apr 91 00:48:36 GMT

In article <530@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:

   The catch is that you may then detect inconsistencies which
   are *not* original errors: for example, they may result from errors
   in the elements that have been added for redundancy. (This occurs
   for example when a variable is used properly, but its declaration
   is ``wrong'' with respect to the programmer's intent.)

   This means that when you add redundancy for security there is a risk
   of false alarm (detecting an apparent error when the original was in
   fact correct). If, as is the case in the practice of reasonable
   statically typed languages, such false alarms are rare, the price
   is acceptable, being justified by all the *real* alarms that
   redundancy will enable you to catch.

Yes, I agree completely, and here's another analogy that people might
like.  Consider parity checking on computer main memory.  Adding
parity bits allows a consistency check, so that you can easily
recognize when one of the stored bits in memory is incorrect.  The
catch is that perhaps the parity bit itself might have the wrong
value!  In this case, you actually would have been better off without
the parity bit.  However, I think most people can see why, despite
this catch, there's quite a lot to be said for the parity bit, and
most people would rather have parity checking than no checking, and
are willing to pay for it.

This isn't a perfect analogy for all aspects of the issue under
discussion, of course.  I just think it's a good way to explain the
business about the "catch", and the risk of false alarm, and why that
might not be as bad some people might at first think.  Whether the
relative costs for various kinds of software construct are similar
to the relative costs for parity checking is not necessarily obvious,
but the qualitative nature of the tradeoff is similar in this way.