"I am one of the few serious mainstream PL researchers who has stood up to 'type research' (as in types are all there is to a PL) for two decades now. Having said that, I still think that a knee-jerk reaction to static type systems is improper. When you maintain untyped code, it does become difficult what the three arguments to your method at line 123,765 represent: closures, objects, integers, and what 'invariants' they satisfy. I have watched a programmer struggle with just that issue, and it is a programmer whom I would trust with my life (as far as programming is concerned). If the types are written down (and checked and sound), you can save yourself some 15 minutes with every method you touch. Sure it adds a few token pieces of type info to the method header, but what's that compared to 20,000 methods touched times 1 - 15 minutes of 'manual type recovery.' And don't tell me about type inference for 'scripting languages'; I have also spent four dissertations and 20 years on this, plus a couple of years of trying to analyze Python, to know better. (It's kind of acceptable if the language is designed for it from the scratch.)"
I've seen this: years ago, I remember walking a (smart) developer who knew Java through some existing Python code, with the intent of teaching the language as well. Biggest obstacle to comprehension? Not knowing what the types of the method arguments were. By comparison everything else was merely odd. Any time I come to old Python code and see an argument called 'file'... well, I don't know, but it's not a good feeling. Method signatures are the only (I think) reason I'd go for optional type declarations in Python.
Here's the other:
"Steve wrote that "folks who wonder about how I could (re)write such a giant system without any "static" type annotations: http://tinyurl.com/26n2zq".
As a co-creator of gradual transformations from dynamically typed to
statically typed languages (see DLS 2006), I am perfectly aware of this
idea. The problem is that Ecmascript's implementation of the idea is
broken, unsound. So whatever advantages you would get from a sound
system, such as ML's or even Java's, you won't get from ES 4. (The most
you get is C's notion of types.)
Nobody has tested this notion on a big style. At PLT, we have ported some 10,000 lines to a sound system. Works like a charm and I firmly believe that soundness was important. When you get a type bug at run-time it's not in the typed part of your code. With Ecmascript, this is not true. You will need to search the whole thing."
Squarely filed under I-had-no-idea-about-that-at-all.
Disclosure: Felleisen is one of my CS heroes. "A little Java, a few Patterns helped me grok a number of object oriented programming ideas.