Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsc!lgm
From: lgm@cbnewsc.att.com (lawrence.g.mayka)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Summary: Catching "type errors"
Message-ID: <1990Oct25.131653.13463@cbnewsc.att.com>
Date: 25 Oct 90 13:16:53 GMT
References: <1990Oct9.190813.23402@ux1.cso.uiuc.edu> <2444@runxtsa.runx.oz.au> <45940@apple.Apple.COM>
Organization: AT&T Bell Laboratories
Lines: 33

In article <45940@apple.Apple.COM>, lins@Apple.COM (Chuck Lins) writes:
> In article <1990Oct19.180646.8649@ux1.cso.uiuc.edu> render@cs.uiuc.edu (Hal Render) writes:
> >Assuming that any software you write is thoroughly tested, most 
> >type errors that would be caught at compilation can be caught during
> >testing.  
> 
> First, "most" is not the same as "all". Second, you may be forgetting the
> relative costs here. A compilation of a few seconds (or even minutes) costs
> far far less than the hours or days it takes to thoroughly test software. We
> are talking orders of magnitude here.

First, your cited costs are system-dependent.  For some software
systems recompilation takes hours or days, but incremental testing
takes seconds or minutes.

More importantly, though, the vast majority of type "mismatches"
detected by typical compile-time typing are not errors at all, but
rather artificial limitations on algorithmic capability.  In such
cases, a dynamically typed system is not "letting incorrect types
pass" but rather dealing with arbitrary objects correctly and
elegantly, without artifical type restrictions.  Instead, any object
which offers the operations required in a particular circumstance
(e.g., the operations actually invoked on a received argument) fulfils
the protocol.  This criterion of behavioral correctness instead of
representational correctness is even more important in continuously
evolving systems.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.