Update: See the comments.
The paper by Meijer and Drayton is making the rounds. As long as Microsoft supports the popular "dynamic" languages I don't care much what other languages they support.
Since the paper is a work in progress and they admit to being provocative, I may as well comment...
First of all I would note that the term "test" does not show up anywhere in the paper. This is a bit of a shock for a paper whose opening sentence is...
Advocates of static typing argue that the advantages of static typing include earlier detection of programming mistakes.Moving on to a few unsubstantiated claims...
data intensive applications need to deal seamlessly with several degrees of typednessI did not see a definition of "data intensive" nor did I see evidence of what this "need" is.
not inferring the types of these variables whenever possible is literally throwing the baby with the bath waterEverything has a cost/benefit ratio, which informs the answer to "whenever possible". I could not find a description of this ratio in spite of that being the topic of the paper.
in general programmers want to express more advanced contracts about their codeYes, but the question is how, and at what cost. Testing, even model checking, could be brought into this discussion. The benefits of the specific proposals in the paper are not clearly proposed.
The compiler should verify as much of a contract... as it canMore of the same... "as much as possible", "as much as it can"... the problem is the paper should propose some eveluationc criteria otherwise it is your word against mine. I will go with my word every time in that case.
Perhaps the most useful example [of coercive typing] is "auto-boxing" from value types to reference typesIf that's the best example then... ahem. One could simply choose a language that does not even have such things that contribute nothing to the real problem.
the compiler can automatically "lift" addition on normal integers to addition on nullable integersOne could simply choose a language that does not even have such things that contribute nothing to the real problem.
[generics make it] possible to create highly reusable languages, while maintaining the benefits of compile-time type checkingThose benefits have a cost. The point is people disagree on the accounting of the cost/benifit ratios. The paper does not propose an accounting that can be examined.
I want lazy evaluation... the power of the Unix shell lies in the fact that programs consume and produce lazy streamsAgreed. But this has nothing to do with type checking. Maybe this would make a better paper than one on type checking for many readers.
Overall the paper has some ideas on how typical type checkers for C# and Java can be improved. That these checking approaches would be better than "dynamic" languages seems to be an assumption the authors chose not to question. Too bad, I thought that was the point. I don't see many people arguing to stick with the poor checking done currently by C# and Java.