4 ms·

They certainly require more effort from developer to be as reliable as programs on statically typed languages. Compare theoretical absence of certain errors (ty

by thesz 16y ago

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. All my friends who happen to write some substantial code in Javascript now search for translators to Javascript from other languages and lints and typecheckers for Javascript programs. Number of those my friends is about four, but they are unanimous. Also, smallish UI centric code is just one case of Android apps. Nethack, for example, you can't call it small and UI-centric: http://www.androlib.com/android.application.com-nethackff-zzxC.aspx http://www.androlib.com/android.application.com-nethackff-zz... GUI for Nethack is nonexistant, but logic isn't trivial.

fauigerzigerk 16y ago
Statically typed code is only type-safe as long as you don't use any meta programming techniques. But that means you have to write and test much more code. More code means more errors. Also, being forced to test more may cause dynamically typed code to be more reliable at the end of the day. But that's all speculation. I don't think we have any empirical evidence on that and hence I disagree with the general claim that dynamically typed languages are less reliable. I write mostly statically typed code and I do appreciate what the compiler does for me. Also, I find statically typed code more readable and self-explanatory sometimes. It's ultimately faster as well. It's a tradeoff though, and since JavaScript is already present on mobiles anyway, I don't see the advantage of adding yet another VM.
- thesz 16y ago
  >Statically typed code is only type-safe as long as you don't use any meta programming techniques. MetaOCaml: http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml TemplateHaskell: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-haskell.html http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/temp... "A Verified Staged Interpreter is a Verified Compiler (Multi-stage Programming with Dependent Types)": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3609 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3... I think that metaprogramming techniques would only gain from strong types. I don't agree with most points of your comment, but I do not think I have strong arguments against.
  - fauigerzigerk 16y ago
    The MetaOCaml example is certainly interesting but what it does is increase speed, not reliability. In this case, the type (in some general sense) of n is known at compile time, so the compiler can guarantee that whatever is generated at runtime conforms to that type. But that's not the type of meta programming that depends on runtime discovery of entirely new information, say, an ORM that discovers changes in the database schema. That's the type of meta programming that made Rails so popular and productive (and slow) for some cases. Obviously, it is impossible to provide compile time guarantees about something that is unknown at compile time. But I tend to agree with you that it is desirable to have correctness proofs at compile time wherever possible.
sedachv 16y ago
'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).

by thesz 16y ago

fauigerzigerk 16y ago

Statically typed code is only type-safe as long as you don't use any meta programming techniques. But that means you have to write and test much more code. More code means more errors. Also, being forced to test more may cause dynamically typed code to be more reliable at the end of the day. But that's all speculation. I don't think we have any empirical evidence on that and hence I disagree with the general claim that dynamically typed languages are less reliable. I write mostly statically typed code and I do appreciate what the compiler does for me. Also, I find statically typed code more readable and self-explanatory sometimes. It's ultimately faster as well. It's a tradeoff though, and since JavaScript is already present on mobiles anyway, I don't see the advantage of adding yet another VM.

thesz 16y ago
>Statically typed code is only type-safe as long as you don't use any meta programming techniques. MetaOCaml: http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml http://en.wikipedia.org/wiki/Objective_Caml#MetaOCaml TemplateHaskell: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-haskell.html http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/temp... "A Verified Staged Interpreter is a Verified Compiler (Multi-stage Programming with Dependent Types)": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3609 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.3... I think that metaprogramming techniques would only gain from strong types. I don't agree with most points of your comment, but I do not think I have strong arguments against.
- fauigerzigerk 16y ago
  The MetaOCaml example is certainly interesting but what it does is increase speed, not reliability. In this case, the type (in some general sense) of n is known at compile time, so the compiler can guarantee that whatever is generated at runtime conforms to that type. But that's not the type of meta programming that depends on runtime discovery of entirely new information, say, an ORM that discovers changes in the database schema. That's the type of meta programming that made Rails so popular and productive (and slow) for some cases. Obviously, it is impossible to provide compile time guarantees about something that is unknown at compile time. But I tend to agree with you that it is desirable to have correctness proofs at compile time wherever possible.

sedachv 16y ago

'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).