Comment by jnbiche | Hacker News Reader

Comment by jnbiche | Hacker News Reader

Every time I think about what Android could have been, my frustration mounts. Google chose to use Java for the top layer on top of their native code libraries (as in on top of C libraries like surface manager, opengles, openvg, sgl, etc.). Why they chose Java instead of a language that integrates well with C, I just don't understand. It would have made the ecosystem much more open.

I wish they had considered just making the top layer in Luajit, as well as exposing a C API. Luajit would have been just as efficient battery-wise as Dalvik, and perhaps even better-performing. Best of all, people then could have much more easily built libraries for Python, Ruby, and any other language with good C interop.

Instead, we're left with Java. It's not a bad language, but it is very bad at integrating with other languages and platforms.

I prefer Android to iOS, but the iOS architecture is definitely more open to third-party platforms. Unfortunately, Apple is not so welcoming and puts up roadblocks.

Yeah I think Python would have been a good choice. Something that looks like kivy perhaps.

http://kivy.org/#home

Java is just too popular and too average. Has enough people knowing it, works well with an IDE, compiles (and thus hides the source better).

The apps I wrote for example, was more about the API and editing XML files. I've used Java before but in this case it felt different, I would say easier. Not a lot of FactoryFactoryManager type mess many stereotypically associate with Enterprise Java back-ends. So it wasn't too bad.

Another interesting point. At one of the PyCons someone asked Guido publicly (he was still at Google back then), why doesn't Android use Python more? And Guido replied it was a "political decision". Moreover the tone he replied it was betraying that he was a bit upset or annoyed at it. So I imagine there was some internal discussion, perhaps more than one and more than once, and one camp one and one lost.

I would love it if Tcl were a first class option. W/o getting into Tcl vs. Lua vs. Python vs. Ruby vs. Perl vs. Chicken Scheme vs... if the underlying platform really were C, all these things would be viable options. C would have let all these flourish.

I would really love a Python API on Android. Unfortunately, Python as it exists now is way too inefficient to use on a mobile phone. Have you tried running a Kivy app for more than a few minutes and watched your battery run down?

Don't get me wrong -- that's not Kivy's fault really. It's the Python interpreter that's eating up the battery, not Kivy per se. And I'd like to say that there's hope in Pypy, but for the fact that PyPy uses up to twice the memory of regular Python.

Now, there's no reason why Python couldn't efficiently run on mobile, but it'd have to be with an entirely different interpreter, or at least a significantly modified CPython. One that uses a register-based VM instead of a stack-based one, and makes a number of other bytecode and VM changes toward greater efficiency.

Worse, for the Java fans like myself, they really forked Java.

So now Java 8 is around the corner and Android is still playing catchup with Java 7, which is only fully supported on KitKat.

So I end up going with C++, since what I care about is covered by libraries like SDL and openframeworks.

They had a talk about ART planned for FOSDEM and it was:

- cancelled at last minute

- Google was also not letting anyone film the talks on the Java room.

http://neugens.wordpress.com/2014/02/09/fosdem-2014/#comment...

We agree on with native and opening up the platform at Apportable. It's why we built Apportable. It provides everything you expect from iOS on top of Android and makes it just as open for mixing code. We try to fill in the gaps that people with the native experience on Android.

Apportable doesn't let you build libraries. You can only translate whole iOS apps to Android.

It actually does let you build libraries, but those libraries also depend on Apportable's improved libc and libc++ environment and other libs you link. Admittedly the documentation is lacking how to do that exactly. That will improve soon.

Apportable's promise is huge. The prospect of being able to compile the same project for both iOS and Android makes me want to jump. But the platform is not quite there yet, as far as I know.

Without divulging anything, I can safely say it's responsible for at least 32 apps that made it in the Google Play Top 100 games last year, so it's doing pretty good.

For anyone else that wants to focus on iOS where they will make the most money but not compromise on Android and provide it with the same experience without having to rewrite everything, it's working great. I will say that if you are building a game it works out of the box today better but we have a lot of people using in ways we could never imagined.

The newly rewritten UIKit support is coming soon which will make it a viable solution for anyone that wants a single push button solution for all kinds of apps. For a few users, they choose to use the native UI on Android and bind that to their Objective-C/C++ backends with Apportable. There are a lot of options with Apportable.

Reply on news.ycombinator.com