In the hands of a really capable developer, JavaScript can be used to engineer reliable, complex systems. Sadly, most people who write software for a living are not "really capable", so the extra safety net provided by compile-time type checking and good IDE support that comes with Java tends to outweigh the concision and flexibility of a dynamic language like JavaScript.

Also, while V8 is quite heavily optimized for performance on modern PCs, I haven't seen much to support the idea that it is a great fit for memory and CPU-constrained mobile devices. Early versions of Dalvik specifically traded runtime compilation (as implemented in HotSpot and most other modern JIT-ing JVMs) for ahead-of-time in order to minimize the memory footprint of applications. Any VM designed around heavy runtime optimization (like a mobile V8 derivative) would have to be carefully tweaked to not thrash horribly given the memory constraints on most smartphones.

I don't see that optimizing the V8 JIT for that purpose would be more difficult than creating an entirely new VM. Actually I think that V8 is used in Android anyway.

I don't have anything new to add to the age old debate about dynamic vs static typing in general. I'm not firmly in one or the other camp on this one. I just don't see the empirical evidence for the much touted greater reliability of statically typed languages (nor for the equally much touted greater productivity of dynamically typed languages)

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-zz...

GUI for Nethack is nonexistant, but logic isn't trivial.

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

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.

>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 TemplateHaskell: 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.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.

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.

"Smallish UI centric code"--no. Virtually all of that OS is written in Java.

That's very far from the truth. But anyway, we were talking about the language in which apps are written, not some component of the OS itself.