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