Re:No Java 7, The End Game
by sedachv on Tuesday October 12, 2010 @03:52PM
(#1784660)
'They certainly require more effort from developer to be as reliable as programs on statically typed languages. Compare theoretical absence of certain errors (typos, for example) with probable absence of them.'
Just because some JavaScript implementations don't provide compile-time reference checking and type inference, doesn't mean it's not possible, or even particularly hard. See for example the kinds of warnings SBCL provides at compile time (they are not far off from the stuff you'd see from a Java compiler). People have been writing very large, reliable programs in Lisp for 40 years now.
Java's type system is completely broken (what else do you think the implication of having every type be "or null" is?) - in practice this means the difference in number of errors stemming from bad types between Java and programs written in dynamically typed languages is much less than you think. The way forward is languages with a logically sound type system that supports inference and polymorphism (and today this means Haskell or ML and derivatives).
Just because some JavaScript implementations don't provide compile-time reference checking and type inference, doesn't mean it's not possible, or even particularly hard. See for example the kinds of warnings SBCL provides at compile time (they are not far off from the stuff you'd see from a Java compiler). People have been writing very large, reliable programs in Lisp for 40 years now.
Java's type system is completely broken (what else do you think the implication of having every type be "or null" is?) - in practice this means the difference in number of errors stemming from bad types between Java and programs written in dynamically typed languages is much less than you think. The way forward is languages with a logically sound type system that supports inference and polymorphism (and today this means Haskell or ML and derivatives).