"Strong typing vs. strong testing"

namekuseijin namekuseijin at gmail.com
Mon Sep 27 13:46:32 EDT 2010


On 27 set, 05:46, TheFlyingDutchman <zzbba... at aol.com> wrote:
> On Sep 27, 12:58 am, p... at informatimago.com (Pascal J. Bourguignon)
> wrote:
> > RG <rNOSPA... at flownet.com> writes:
> > > In article
> > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b... at q16g2000prf.googlegroups.com>,
> > >  TheFlyingDutchman <zzbba... at aol.com> wrote:
>
> > >> On Sep 22, 10:26 pm, "Scott L. Burson" <Sc... at ergy.com> wrote:
> > >> > This might have been mentioned here before, but I just came across it: a
> > >> > 2003 essay by Bruce Eckel on how reliable systems can get built in
> > >> > dynamically-typed languages.  It echoes things we've all said here, but
> > >> > I think it's interesting because it describes a conversion experience:
> > >> > Eckel started out in the strong-typing camp and was won over.
>
> > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>
> > >> > -- Scott
>
> > >> If you are writing a function to determine the maximum of two numbers
> > >> passed as arguents in a dynamic typed language, what is the normal
> > >> procedure used by Eckel and others to handle someone passing in
> > >> invalid values - such as a file handle for one varible and an array
> > >> for the other?
>
> > > The normal procedure is to hit such a person over the head with a stick
> > > and shout "FOO".
>
> > Moreover, the functions returning the maximum may be able to work on
> > non-numbers, as long as they're comparable.  What's more, there are
> > numbers that are NOT comparable by the operator you're thinking about!.
>
> > So to implement your specifications, that function would have to be
> > implemented for example as:
>
> > (defmethod lessp ((x real) (y real)) (< x y))
> > (defmethod lessp ((x complex) (y complex))
> >   (or (< (real-part x) (real-part y))
> >       (and (= (real-part x) (real-part y))
> >            (< (imag-part x) (imag-part y)))))
>
> > (defun maximum (a b)
> >   (if (lessp a b) b a))
>
> > And then the client of that function could very well add methods:
>
> > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > (defmethod lessp ((x string) (y string)) (string< x y))
>
> > and call:
>
> > (maximum 'hello "WORLD") --> "WORLD"
>
> > and who are you to forbid it!?
>
> > --
> > __Pascal Bourguignon__                    http://www.informatimago.com/-Hide quoted text -
>
> > - Show quoted text -
>
> in C I can have a function maximum(int a, int b) that will always
> work. Never blow up, and never give an invalid answer. If someone
> tries to call it incorrectly it is a compile error.
> In a dynamic typed language maximum(a, b) can be called with incorrect
> datatypes. Even if I make it so it can handle many types as you did
> above, it could still be inadvertantly called with a file handle for a
> parameter or some other type not provided for. So does Eckel and
> others, when they are writing their dynamically typed code advocate
> just letting the function blow up or give a bogus answer, or do they
> check for valid types passed? If they are checking for valid types it
> would seem that any benefits gained by not specifying type are lost by
> checking for type. And if they don't check for type it would seem that
> their code's error handling is poor.

that is a lie.

Compilation only makes sure that values provided at compilation-time
are of the right datatype.

What happens though is that in the real world, pretty much all
computation depends on user provided values at runtime.  See where are
we heading?

this works at compilation time without warnings:
int m=numbermax( 2, 6 );

this too:
int a, b, m;
scanf( "%d", &a );
scanf( "%d", &b );
m=numbermax( a, b );

no compiler issues, but will not work just as much as in python if
user provides "foo" and "bar" for a and b... fail.

What you do if you're feeling insecure and paranoid?  Just what
dynamically typed languages do:  add runtime checks.  Unit tests are
great to assert those.

Fact is:  almost all user data from the external words comes into
programs as strings.  No typesystem or compiler handles this fact all
that graceful...



More information about the Python-list mailing list