Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

It seems Google has a problem on their hands. If I undstand it correctly, Android relies on the Harmony implementation of the Java standard library. So Google will now have to carry those libraries forward on their own.

What I don't quite get is why Google isn't just using V8 to power Android apps. Also, why isn't Android apps development more like writing Chrome extensions?

The main attraction of Java on Android is that so many people know Java. However, a lot of poeple know JavaScript as well, particularly those involved in client side programming. So replacing Java with JavaScript on Android seems like a no-brainer to me. (The threading model might be an issue)

Replacing Java with Go would be more interesting to me personally, but it's a stretch as very few people speak that language yet.

View on HN

I think Java in the sweet spot between program reliability and developer availability. A developer can prevent most variants of uninteresting errors using Java, yet there are many developers.

Android apps works "in the distance" - developer cannot load REPL and fix it while client is on the phone with technical support. So you need pretty solid language, one that helps fixing bugs before they hit customer. Or, at least, a pretense on that.

More solid languages, like Haskell, Coq and Agda2, just do not have enough developers.

Go is good, at least as good as Java, but it also doesn't have big enough community.

So your case is resting on the assumption that JavaScript programs are less reliable than Java programs. That's a pretty bold claim to make in general and particularly for the kind of smallish UI centric code we're talking about.

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

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.

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.

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

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)

Reply on news.ycombinator.com