Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!news.funet.fi!jyu.fi!sakkinen
From: sakkinen@jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.misc
Subject: Re: Run-time Type Errors in Smalltalk
Message-ID: <1991Apr18.052231.25350@jyu.fi>
Date: 18 Apr 91 05:22:31 GMT
References: <2023@optima.cs.arizona.edu>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 45

In article <2023@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>In article  <1991Apr15.234559.16293@comp.vuw.ac.nz> Brian Boutel writes:
> ...
>]The claim that testing catches all errors is laughable.
>
>Sure is.  Did someone make that claim?

That is how I too have understood several of your postings.
You have even added "in a matter of minutes".
Glad to hear you don't really think so.

> ...
>]So what can be said about all the errors in the quoted C++ project that
>]were not caught by testing and are still in the production code? 
>]
>]I'll tell you. They are not type errors.
>
>Nope, you can't tell that.  C++ production code can core dump due to a
>type error.  That's because to implement something that really needs
>dynamic typing you often have to use tricks that leave all type
>checking up to the programmer.

C and C++ are a bad choice to represent statically typed languages
in these comparisons.  C descends from some truly _untyped_ languages
and that still shows.  It has only partial type checking at compile
time and none whatsoever at run time.  C++ is not essentially better.

>What can you say about errors that occur in  production code in
>dynamically typed languages?  First, they are not caused by the
>necessity of getting around the static type checker.  Second, they are
>almost never type errors of the sort that could have been caught by a
>static type checker.  Third, if they are type errors they cannot cause
>a core dump or other unpredictable behavior.

However, there are situations in which "Message not understood"
is not essentially better than a core dump.  Typically, embedded
systems running unoperated.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)