"Strong typing vs. strong testing"

[Squeamizh]

On Sep 27, 10:46 am, namekuseijin <namekusei... at gmail.com> wrote:
> 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/-Hidequoted 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...

I disagree with your conclusion.  Sure, the data was textual when it
was initially read by the program, but that should only be relevant to
the input processing code.  The data is likely converted to some
internal representation immediately after it is read and validated,
and in a sanely-designed program, it maintains this representation
throughout its life time.  If the structure of some data needs to
change during development, the compiler of a statically-typed language
will automatically tell you about any client code that was not updated
to account for the change.  Dynamically typed languages do not provide
this assurance.