Hacker News Reader

Comment by aswanson | Hacker News Reader

A bigger question on my mind has been why would a shop as smart as Google not have started out with a sane language like python in the first place instead of foisting this java idiocy on another generation of devs.

View on HN

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.

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

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

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.

Guido was working at Google and he (I understand) try to "fix" the problem. He was told to back off and when asked about it during one of the PyCons the reply was "it was political" not technical.

Moreover it wasn't just that he answered but also how he answered. One could tell he was upset by it, you could hear it in his voice.

Can you pull up any sources for that?

They're relating their own experience. They are a their own source.

I saw the talk. Guido's answer and tone is characterized correctly.

http://www.youtube.com/watch?v=EBRMq2Ioxsc

Question on mobile/Android starts at 42:30: http://www.youtube.com/watch?feature=player_detailpage&v=EBR...

See below someone someone posted the video

Even more interesting is what the Android guys had to say about getting newer versions of Java. The tone is very suspect and it almost sounds like they are considering another language. Perhaps that's just me reading into it.

Source: http://www.youtube.com/watch?feature=player_detailpage&v=A5O...

http://www.youtube.com/watch?feature=player_detailpage&v=A5O...

Check wikipedia: Android was bought by Google, not created. Also, a critical element of its success was adoption by partners: in this context, preferring Java (very much the "enterprise language") over Python (hackish open-source language with minuscule enterprise presence) was a no-brainer -- hence the "it's political" answer Guido himself got from the upper echelons.

As a python-aficionado, I stopped kidding myself a few years ago: Python will never be mainstream in the way Java or C# are, the number of people working with it will always be small, unless something dramatic happens at the commercial level. It's like Linux on the desktop: the masses are simply elsewhere.

Im saddened by this. But on the other hand, our good friend Oracle is trying to change it by trying to motivate developers to search for a non-Java language.

Trust me, Python is doing very well at Enterprise scale. Here's a taster of what it's about in the below links, which are public information, but the Quartz platform is huge. I wish I was at liberty to discuss it in more depth. If you're keen on Python and willing to work hard, it's worth considering Bank of America Merrill Lynch.

https://us.pycon.org/2013/schedule/presentation/155/

http://careers.bankofamerica.com/JobDetails.aspx?SearchPage=...

Take this with a grain of salt. I found working on Quartz to be much more miserable than any other platform I've ever worked with. Of course, that had to do with a lot of factors that weren't related to the language.

Google should use Go for Android... Cleaner than Java, faster than Java (on Dalvik).

I can imagine how slow Python on ARM Android is.... and people complain about Java code being slow on Android... I would put money on JS/V8 being faster than Python on Android too.

The following comparison is JVM vs Python, so its really pretty far off the scenario we are discussing, but consider it shows almost up to two orders of magnitude difference..

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Non-portable. While android primarily runs on ARM boxes, the same APKs, barring any native code libraries, will run on x86 devices running android, MIPS devices, etc.

Compile on install? Compile to something else then compile to binary? PNaCl?

I would go with "compile on install"

Make Dalvik/JVM a compile target for Go? There is at least one project working on this.

Go is portable... you just need to compile on the target. Go is write once, compile and run everywhere. Compiling would be part of the app install process; Compiling Go is much lighter than compiling C anyway.

NDK also lets you compile one binary for all device architectures now as well.

I think Google should require every app that uses the NDK to provide ARM, x86 and MIPS binaries.

Google should've never cared about making Android work on x86. The ARM environment is an order of magnitude more competitive than the x86 one. So it's not like they need it for the "competition". If they'd like to have Android on PC's eventually, well they don't have to worry about that either, since ARM is disrupting Intel anyway, and will be the architecture of the future, being pushed by both Android and iOS, the most popular platforms right now (and even Windows is promoting it, although in a smaller way).

There are MIPS android devices too, I have one and it works well except when people write junks of their app in C and didn't upload the MIPS binary. Maybe with the recent POWER announcement we will see POWER devices.

Its not clear if the python code was compiled on their benchmarks. That might close the gap.

On the tests where Java was much faster, the Python solutions took minutes. Compilation would not be a big deal compared to that.

It would be great if Go could be used as a reasonable alternative to Java on Android. Or Clojure. Or Python. Or Lua.

You can already use all of these on Android, but any kind of visual programming is a pain in the ass since you have to do Java interop, and start-up is slow because of the apk unpackaging requirements.

I've always wondered this as well. I mean, Google loves Python as evidenced by App Engine, how many of their internal/external tools use Python and other projects I'm forgetting. Basically I would have at least expected it as a built-in option to use (kind of like how Windows Phone 8 has a higher-level and lower-level way of accessing the phone).

App Engine has, if anything, better support for Java than Python.

I might be remembering incorrectly, but wasn't the launch option for App Engine their home-grown version of web.py?

They started with Python and their own webapp framework; Java support came years later.

Can you give some examples of how that is the case? I don't know of any App Engine Services available on Java not available on Python (or vice-versa). They seem to be equally supported.

It's Go & PHP that are in "Experimental" mode. (per https://developers.google.com/appengine/)

We will never know.

I guess because Python is not statically typed. Most of the efforts they have been supporting (golang, dartlang...) are evidence of they prefer to have Static type-checking around.

I think personally that it might have to do with sandboxing python, so third-party apps could be run safely, stopped, restarted, etc.

I think this decision was made by Android Inc. before Google purchased them.

I think they answered that question, and you can probably find it with a Google search - but the reason was this: Python was too slow, especially for the time, which I think is already an uncontested fact.

But for the future? Yeah, I can only hope Google is working on switching Android to Go in a few years. It doesn't even have to be an abrupt change - which definitely won't be - they're not insane. But they can add the language in the NDK or something, and then just promote it to developers as the main language they should be using when making new Android apps.

By providing a true API-compatible JVM implementation, they did the opposite of "foisting" -- they provided a way for you to run any JVM-compatible language you want. That, after all, is why we can run Clojure, Scala, and what-have-you as first-class languages on Android with access to all the same APIs as Java.

It is true, of course, that they chose Java as the default language for Android development. I imagine this is because dynamic languages were not always practical on early smartphone hardware, and because there was already a large ecosystem around Java from which they could draw.

Just having gone through about 18 steps to install Python 2.7 on my server because we have code that only runs in 2.7, while most of the operating system only works with 2.6 and breaks with 2.7, and seeing all the backwards compatibility cluster fuck that is Python3k, I think anybody would be crazy to base an operating system like Android on Python.

You can't have backwards compatibility and your progressive "keep language simple and clean by dropping features" at the same time.

Whis OS is this?

CentOS6. Partly just expressing frustration on my part, but definitely sours my view on basing things on Python for something where stability is a priority. On the otherhand, virtualenv is a god send ....

virtualenv is your friend

How the hell does drivel like this get upvoted?

Reply on news.ycombinator.com