Hi,

I think there have been many good, informative, responses from people.  I
just want to add that in my own experience in C, compile-time type
checking only helps me in finding the wrong type of pointer (when I forget
to cast it); however, compile-time type checking does not help at all when
the address itself is wrong, which then usually results in a crash.

The first time I used a scripting language, I was also wondering, won't I
make more errors if there is no static type?  In C, for example, I will
get an error such as "struct has no member with name 'name'" when I
mistype.  Actually, this will be a good example, as in Python you will not
get an error in this code:

    x.cunter = 1    # when we mean 'counter'

but you will in Ruby (when you run it).  Therefore even without
compile-time type checking, assuming that you will test and run your code,
you will get a lot of help from the Ruby interpreter, sometimes more than,
for example, that in Python.  (This is one of the reasons why I switched
from Python to Ruby.)

Really, I agree with the people who mentioned to just try it.  Once you
are used to coding in a scripting language, you will not miss compile-time
type checking very much.  What you will miss is execution (and
memory) performance.  When a "real application" has certain requirements
regarding memory and execution performance, then usually scripting
languages are out-of-the-question.

Regards,

Bill
=============================================================================
Volkmann, Mark <Mark.Volkmann / agedwards.com> wrote:
> That is what I meant.  It seems to me that having compile-time type checking
> allows certain coding errors to be found more quickly and reduces the
> possibility that users will experience the equivalent of a Java
> ClassCastException or whatever happens in Ruby when you attempt to invoke a
> method on an object that doesn't support it.