Other Android Languages

I’ve been having this same conversation with a variety of programmers in recent days, and so I ought to share it with the world. I think it would be nice if you could build Android apps in other languages. The leading candidates seem to be Ruby and Python. People are working on it. This is my take on the state of play.

[Sidebar:] As it says in the sidebar, I don’t speak for Google, which is especially true here. The Android leadership at this point is focused on improving the platform, the devices, and the current programming tools; nobody has a mandate to work on other languages. Of course, I wouldn’t be paying such close attention if I didn’t think this work would give Android a major shot in the arm, but don’t expect any Google VIPs to agree.

Why · I like the Android platform a whole lot, with its Activities and Services and Intents and Listeners and ContentSources and so on; it seems to have pretty well everything you need to write interesting apps, and there’s very little about it that gets in the way or requires unnecessary work. I also like it that it assumes the presence of the Apache Harmony libraries, which are comprehensive, robust, and well-debugged.

On the other hand, I do not particularly like the Java programming language. Hmm... that’s an overstatement. In those situations where I want a C-flavored statically-typed language with a really good compiler, Java is the way to go.

On the other hand, I can get more work done faster in a dynamically-typed language like Python or Ruby. Also, any given task usually requires fewer lines of code, which is an unambiguously good thing. Also, programming with them is more fun (if you think that doesn’t or shouldn’t matter, you’re wrong). Also, they make it easier to do good unit testing without jumping through dependency-injection hoops.

This view is not shared universally. Plenty of people, in including many at Google, feel that static typing is essential to developing serious industrial-strength software. I am generally unpersuaded except perhaps in the case where there’s a substantial team building a big sprawling system; but then, most Android apps aren’t like that.

And finally, as a citizen primarily of the Web, I can’t help but notice that in recent years, its interesting bits (Facebook, Wikipedia, Twitter, 37 Signals, Ravelry) are largely not being built in Java. I know first-hand that there is a substantial community of really first-rate programmers, people I admire, who for one reason or another just don’t want to deal with Java; and I’d like some of them to become Android developers.

What · I’m focusing on Python and Ruby, because they are the most mainstream of the dynamic languages. Yes, I know about Perl and Clojure and Scala and Factor and Lua and any number of Lisps and JavaScripts.

Thus, here are the conditions that I think, if met, would define success in this project.

A version of Python or Ruby that is more or less feature complete on Android, and
which runs at acceptable speed; in particular has no perceptible startup latency, and
makes it easy to build real Android applications. That is to say, offers access to each and every function and data field in the Android API in a way that’s simple and idiomatic.

How · One obvious idea, since both Python and Ruby now have implementations written in the Java language, and although Android isn’t a Java platform it can compile such programs, would be to run Jython or JRuby.

In fact, this has been done for JRuby; you can go get Ruboto right now in Android Market; with an IRB command-line and simple script editor, even. JRuby also appears in Scripting Layer for Android (SL4A), formerly the Android Scripting Environment, of which more later.

Ruboto meets criteria #1 and #3, but not #2; it takes several seconds to start up and initialize itself so it’s not practically usable. I know the JRuby community thinks they can make huge strides in startup time and if they’re right, this would be a very attractive candidate.

Jython as a project hasn’t been making very fast progress; since Frank Wierzbicki left Sun, nobody’s getting paid to work on it. I suspect there may be some architectural issues in getting Jython to work on Android, based on the way it generates runnable code; but nothing that couldn’t be fixed given some dedicated resources. Then we’d find out whether it met criterion #2.

But maybe we’re barking up the wrong tree; both Python and Ruby are written in C and run well on Linux boxes, which is what Android devices are. In fact CPython has already been ported to Android as part of SL4A; I can’t imagine that Ruby would be that much harder. Also, I’m confident that they’d start up quickly and run acceptably fast.

That would leave criterion #3; hooking them up to the Android APIs so you could write real Android apps. You can in fact call back and forth between C code and the Android application framework using the JNI bridge, but it involves a certain amount of ugliness, and that’s not acceptable; I want, in Ruby or Python, to write a one-liner to make a phone call or connect to a data source. When I talk to Rubyists about this, they invariably get misty-eyed and start muttering about DSLs; well, maybe.

So I suspect that designing and engineering the connector code would be quite a bit more work than porting the actual language. SL4A accomplishes this via a “facade” mechanism that I haven’t really studied but involves messaging with a JSON payload, and doesn’t so far cover the whole Android platform.

Having acknowledged the difficulty, I can’t think of an architectural reason why this C-language approach shouldn’t work. The Android team takes game developers seriously, and their problems are similar: they want to hook up great big globs of C/C++ to the Android platform to build the game packaging; the parts that aren’t about squeezing the max frame-rate out of OpenGL.

Another approach is to change the language. An example of this approach would be the project launched by Charles Nutter originally called “Duby” but now known as Mirah; it’s a very-much-like-Ruby language that’s had the addition of just enough explicit static typing to make it compilable into conventional bytecodes, whether Java or Dalvik.

It’s not just a theoretical project; follow the pointers from Charles’ tweet to run a silly program called Garrett on your Android, or to view its source code.

Unlike the other approaches I’ve touched on so far, Mirah meets both criteria #2 and #3. The question is whether it passes test #1; will it become “really Ruby” to the extent that it makes Rubyists happy? And is there an equivalent for Python; are PyPy and RPython relevant here?

SL4A · Whatever the right answer is, some of the work done in what we used to call the Android Scripting Environment will surely go into it. They’re not trying to solve the same problem I am; they want to empower people to knock off little scripts right there on the phone; which is interesting, but I want to write big substantial Android apps using the nice tools on my computer with effortless built-in access to all those nice Android APIs.

But they’ve cracked some very nontrivial porting nuts and figured out one instructive way to expose Android’s APIs to whatever programming language comes along.

My Bet · Someone will have something running well enough to be useful by early 2011. If you’re working on something in this space, please make sure I’m aware of it.

Contributions

Comment feed for ongoing:

From: JulesLt (Jul 29 2010, at 03:36)

Looking at MacRuby, and the performance gains it has achieved over interpreted Ruby, the indirect gains inherited from LLVM, and close integration with the 'Obj-C' runtime, I think the Mirah approach sounds like the best one to me.

Develop interpreted, then compile for performance.

Perhaps there needs to be some push towards implementing more 'dynamism' in the underlying runtime, if the official Android SDK doesn't directly expose it?

Or alternatively, we could go down the route of inventing DI frameworks

and logic and type definitions out into (uncompiled) configuration files.