"Strong typing vs. strong testing"

[RG]

In article 
<996bd4e6-37ff-4a55-8db5-6e7574fbd8e1 at k22g2000prb.googlegroups.com>,
 Squeamizh <squeamz at hotmail.com> wrote:

> 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.

This is a red herring.  You don't have to invoke run-time input to 
demonstrate bugs in a statically typed language that are not caught by 
the compiler.  For example:

[ron at mighty:~]$ cat foo.c
#include <stdio.h>

int maximum(int a, int b) {
  return (a > b ? a : b);
}

int foo(int x) { return 9223372036854775807+x; }

int main () {
  printf("%d\n", maximum(foo(1), 1));
  return 0;
}
[ron at mighty:~]$ gcc -Wall foo.c
[ron at mighty:~]$ ./a.out 
1


Even simple arithmetic is Turing-complete, so catching all type-related 
errors at compile time would entail solving the halting problem.

rg