Hacker News Reader

Comment by nly | Hacker News Reader

Java has a granular, stable and simple byte code, Python does not. Java is amenable to static analysis, mainline Python isn't. Dynamic typing means more runtime, burns more battery.

Java also allowed them to leverage a mature and highly optimized frontend. Back in 2008, Psyco/PyPy was there... but fairly wet. Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM.

View on HN

>"Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM."

That's not true -- PyPy had an experimental JVM backend early-in, but the first and flagship backend has always been the RPython one.

Maybe he is thinking of Jython?

You're correct, I was muddling up the projects (I really don't use or have an interest in Python)

I thought RPython was only translated to C and compiled ahead-of-time.

You're right about that. To make a more correct analogy, I should have said that the main target has always been C, which RPython "transpiles" into. So the original and primary target has always been portable C, but there have also been experimental JVM, CLR, and JavaScript targets.

I generally agree with everything you're saying. But as a counterpoint, Dynamic typing doesn't necessarily have to translate to more battery consumption. Objective-C is pretty close to Python when it comes to dynamic typing (also similar in ref-counting for memory management).

Absolutely correct. Lua, for example, does fine on mobile phones. Python pushes the limit wrt to memory and battery consumption, but if you code conservatively and make judicious use of Cython or native code libraries, you can do OK. Incidentally, Python performance seems just fine for GUI programming on modern mobile phones (based on personal experience). But because of the way you have to package Python/Lua/Ruby programs, it takes a long time to open them. But once they are open, they all do fine (and Lua does fine any way you want to measure it).

As someone developing on Android, I so wish that Google had opted for native code on Android, and a native toolchain SDK, which would have allowed people to use almost whatever language they wanted: C, C++, Python, Lua, Ruby, etc. If that had been the case, I suspect most people would opt to use C or C++ for the backend, and code the frontend GUI in Python, Lua, or Ruby.

And yes, you can use the NDK now, but everything visual has to pass through Java.

I so wish that Google had opted for native code on Android, and a native toolchain SDK

100X this. Android's platform APIs are now trapped in Javaland. That is just totally inexcusable.

I sort of imagine the decision to use Java was a conservative one. "No one gets fired for choosing Java". But they forgot the memo that Java is for applications, not systems programming.

Microsoft seemed to be going down the same road some years ago with .Net, only to back out and realize the same thing. Now it's back on C++.

> Until recently(?) the primary JIT back-end for PyPy was, in fact, still the JVM.

This sounds false. The PyPy Features page does mention that PyPy will run on the JVM, but that it is incomplete there, and in particular they don't have their JIT ported to it yet. Do you have any source on that?

PyPy has had experimental backends for JVM, CLI and LLVM, but AFAIK, none of them have ever been the primary backend.

It also had a JavaScript target in the beginning. Pretty cool. But I understand why they had to drop those to concentrate on their primary RPython backend. Since building a fast, self-hosting compiler was one of the main goals of the project (another major goal being to create a JIT compiler framework for any language to adopt, which PyPy is great at but no one knows it).

Reply on news.ycombinator.com