Yes, basically I’m talking about Java (and C# and other pop static languages) and ‘enterprise systems’ (not math or scientific applications of any kind) just because that’s where I have experience.

Anyway, in the first link you sent he author states exactly my point about typing system != design by contract:

Both a and b can possibly be null, so what happens if null is passed? Er, you get a NullPointerException. Some programmers will specify that in documentation for the method, or just write that null is not allowed. The same method in Scheme would be callable with any values at all, though it would fail. That changes the attitude of calling programmers. Instead of looking at the half-hearted type signature, and seeing that null is a possible value, the programmer is more likely to look at the implementation.

The second link is very interesting and mind blowing, but still doesn’t add much light into this debate, I think. Actually I got the impression that, as the author says about problems that are for dynamic vs. problems that are for static, business software development may be something for dynamic languages. Don’t know, just thoughts.

As I said I focused on the type system implementations I know and reading the links I got the feeling that most nice features from static typing languages are, actually, features from the language and not from the fact that they’re static typed (and that’s probably why Scala and Haskell are always the only implementations of static typing people use in the debate). I never said that you can’t create a good programming language using static types, my point (and I think that Jay’s also) is that static typing ‘per se’ won’t give you an advantage in the scenarios described above.

I also said that I can’t think about scenarios where static typing would be better but it’s not because I can’t think of one that they don’t exist
I’ll add a follow-up in the bottom of the post clarifying these points.

Thanks for the links, added your blog to my readings.

cheers