"Strong typing vs. strong testing"

[Squeamizh]

On Sep 29, 3:02 pm, RG <rNOSPA... at flownet.com> wrote:
> In article
> <996bd4e6-37ff-4a55-8db5-6e7574fbd... at k22g2000prb.googlegroups.com>,
>
>
>
>
>
>  Squeamizh <sque... 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/-Hidequotedtext -
>
> > > > > - 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

In short, static typing doesn't solve all conceivable problems.

We are all aware that there is no perfect software development process
or tool set.  I'm interested in minimizing the number of problems I
run into during development, and the number of bugs that are in the
finished product.  My opinion is that static typed languages are
better at this for large projects, for the reasons I stated in my
previous post.