Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <60700004@inmet>
Date: 11 Oct 90 16:50:00 GMT
References: <0yw10qr@Unify.Com>
Lines: 35
Nf-ID: #R:<0yw10qr@Unify.Com>:-19:inmet:60700004:000:1568
Nf-From: inmet.inmet.com!stt    Oct 11 12:50:00 1990


dlw@odi.com writes:
> /* Written 12:12 am  Oct 10, 1990 by dlw@odi.com */
> In article <60700003@inmet> stt@inmet.inmet.com writes:
> 
>    In general, I would argue that if there are no
>    machine-enforceable static constraints on a complex
>    system, then the programmers themselves must have no
>    idea whether any given line of code is right or wrong,
>    except through (inherently infeasible) exhaustive testing.
> 
> . . . The implied
> assertion above, that a lot of testing is needed in the absence
> of static checks but that testing can be dispensed with in the
> presence of static checks, is an exagguration.

I am sorry if I allowed you to infer this assertion.  I certainly
don't believe it myself.  Instead, my point was that most
programmers *do* have statically checkable rules which allow
them to use code-reading (aka bench-checking) as an important step in 
debugging.
Generally, some of these statically checkable rules are well enough defined
that they can be communicated to a compiler.  My point was
that if there is really *nothing* statically checkable, then it
must be impossible to bench-check code, or for that matter write
it in the first place with any idea of whether it would work.

Of course, to really know if it works, it must always be tested.
But an ounce of prevention (static checking) is worth much more 
than a pound of cure (dynamic testing) for most complex systems,
since it is so hard to perform exhaustive testing.

S. Tucker Taft     stt@inmet.inmet.com   uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA  02138