Darrell Norton's Blog [MVP]

I agree with Isaac Gouy's comment on Bruce's post, I think static typing is good because it moves more of the error checking into the compiler, rather than making you find it manually when you are testing. While its true that type-checking is done at runtime as well, it seems to me that you can benefit more from type-checking at compile, and I believe that those benefits outweigh the costs of static typing.

Bruce makes a good point that generics will help greatly reduce the number of runtime type errors, because it will check that your ArrayList<int> will only contain ints, whereas without generics, the ArrayList could potentially contain any type.

I like static typing because I think it reduces bugs in my code, but at the same time I realize that sometimes in order to write "generic" code I have to write code that is dynamically typed, and handle type related run-time errors. Is it OK to like both?

In response to both comments, yes it's ok to do both! I'd like to see as much static checking as possible using type inferencing, but without the static typing limitations.

Using Python I've gotten spoiled not having to jump through hoops to declare and cast variables to the "right type" in order to make the compiler happy, but which does nothing to actually implement the system.

With Static type checking the developer finds the problem while it is still in development. With Dynamic type checking it may be the customer who finds the problem later.

If you have a dynamic typing problem that your customer finds instead of you, then you haven't tested your application enough. Static type checking is vastly more limited than actually exercising the program (which you get with dynamic type checking, at least if you test properly).