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.

  1. A version of Python or Ruby that is more or less feature complete on Android, and

  2. which runs at acceptable speed; in particular has no perceptible startup latency, and

  3. 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:Comments feed

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.

[link]

From: Ted Wise (Jul 29 2010, at 04:58)

The big problem isn't getting any particular language ported to a mobile platform, they are full-featured computers after all. The problem is efficiency.

Apple may be paranoid about it, but Google isn't far behind. Both companies want languages that don't expend too many CPU cycles or chew up too much memory since the first will kill your battery and the second is a limited resource.

Dynamic languages on the mobile environments can't become mainstream until they have mobile implementations that approach compiled languages in efficiency. Whether that efficiency is reached in implementation or terseness is another question.

[link]

From: Atrawog (Jul 29 2010, at 07:13)

People talk a lot about programming languages, but what they actually mean are frameworks and libraries.

There is no Java equivalent to e.g SciPy (http://www.scipy.org) or PyEphem (http://rhodesmill.org/pyephem/). And even if there where learning how to use them and rewriting your existing software completely would take a lot of time.

Doing a bit of Python programming ala SL4A is nice, but without the possibility to use additional Python libraries its usage is somewhat limited.

I have no clue what the future will bring, but if I have to guess it think we will end up with something along the lines of Fink (http://www.finkproject.org) for Android sooner or later.

[link]

From: Doug (Jul 29 2010, at 07:34)

You can already make android apps with scala.

What's the point of all that work though, if what you end up with is only an android app. You have to start over from scratch if you want the port the app to ios (iphone, ipad).

So, I'm leaning more to HTML5-based apps now. Future versions of browsers will hopefully add a <device> tag to access the camera, microphone, and so forth, but we already have canvas and 3d and support for touch input (swipes, etc.) and gestures.

So check out languages and tools that compile to javascript instead of jvm (or dalvik) bytecode, such as coffeescript, processing.js, etc.

[link]

From: Jean-Baptiste Queru (Jul 29 2010, at 07:38)

The entire set of public Android APIs (for each revision of the API) is stored as a single large xml file in the Android source tree.

Auto-generating bindings from that file might be a solution to the bindings issue. It would clearly be a large investment, but it'd be a one-time investment, as there'd be no need to chase each new API in each new version to manually create bindings.

[link]

From: Robert Young (Jul 29 2010, at 07:50)

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

Exactly. Kind of the unix notion of composition of small programs.

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

Java, for quite some years now, is COBOL: the language of corporate programming; not much else. It really should be renamed, either javBOL or COBava.

@Ted Wise:

languages that don't expend too many CPU cycles or chew up too much memory since the first will kill your battery and the second is a limited resource.

Perhaps the answer is Flash with a SSD driver under SQLite (or similar). You move local data to the SQL engine on dense and cheap Flash, saving DRAM for code. This would entail writing RDBMS explicit code in the applications, which may not be to the liking of typical client coders. The 25nm parts are due in a few months.

[link]

From: Xavier (Jul 29 2010, at 07:59)

If the intent is to add some static typing to the python code, one could accomplish translation of said code through the epydoc comments, which support providing parameter type and return type for every method.

The only real issue would be the fact that there is no real standard for epydoc types, so one would have to be determined.

[link]

From: Oscar (Jul 29 2010, at 08:45)

Along similar lines, there's Appcelerator's Titanium SDK, which lets developers write native android apps using Javascript. Not everything about the API is supported yet, but it is open source.

http://developer.appcelerator.com/

[link]

From: Carlos Cardona (Jul 29 2010, at 08:48)

I am not working on anything particularly interesting in this space but I too have been hoping that Ruby would be a development language for Android. Android is by far the most exciting mobile platform right now. The pace of innovation is staggering.

Yet too many developers are turned off by Java. There is a HUGE resource of Android developers out there who would build apps for the platform if only it weren't so verbose and stiff. I hope that you are right and that we see some major movement in this area by early 2011.

Thanks Tim!

[link]

From: Cedric (Jul 29 2010, at 10:01)

Fewer lines of code is not ambiguously a good thing. A few counter examples include code that is so terse that it's unreadable (looking at you, Perl) and code that removes critical information, such as types, thereby preventing tools such as compilers or refactoring IDE's from being able to reason about your code. Fewer lines of code can also make it hard for external developers to understand, modify, maintain and improve your code.

The fact that there are such code bases out there is a strawman: just because the code was written this way doesn't mean it was the best way to proceed for large projects.

Tim, I'm curious: have you had to work recently on projects over 100,000 lines of code in Python and Ruby with a team of 10+ people all sharing pieces of that code?

Your strong stance against statically typed languages makes me think the answer to that question is "no" and whenever I hear this kind of argument, it usually comes from people who are mostly hacking code on their own on small open source projects but that don't have any constraints to work with a team.

Just wondering...

[link]

From: Jason (Jul 29 2010, at 10:38)

Ruby? Bleh, Javascript would be hundreds of times better. Its used by a vastly larger audience, and Google is already doing great things to improve it.

[link]

From: Preston L. Bannister (Jul 29 2010, at 10:43)

If Android 2.0 already includes the v8 Javascript engine, seems this is the logical place to start. The Google folk are going to continuously push improvements, as this is a critical component of the web browser. Anything else is going to have to expend considerable effort just a reach and keep an equivalent level in the basic engine.

That leaves two questions:

1) Can the v8 Javascript engine bundled with the web browser be re-used (at the library level, not source) for other Android applications?

2) How much work is needed to create bindings to the Android APIs?

Ideal would be to find the v8 engine for the web browser in a library that other Android applications could re-use.

Is reflection in Dalvik sufficient to create bindings to Android APIs, callable from v8 Javascript?

[link]

From: Manfred Moser (Jul 29 2010, at 11:11)

I am not sure I agree with a lot of the Java bashing notion. Sure it deters many developers, but it also attract at least as many. The verdict of what has a larger impact will stay unknown.

However in general I believe that more choice is better so I applaud all those efforts, even though personally lean towards Cedric's point of view. For that reason I will be investigating Scala together with Proguard to write Android apps out of curiosity mostly. That might give me the best of both worlds..

[link]

From: Dave (Jul 29 2010, at 11:37)

Android 2 includes the V8 VM so it would make sense to support JS for app development. This seems like the path of least resistance as far as dynamic languages are concerned.

[link]

From: CCs (Jul 29 2010, at 11:40)

How about using Scala?

Compiles to JVM and tastes like dynamic language.

[link]

From: Tom Rothamel (Jul 29 2010, at 11:59)

Is there a project to create a CPython/JNI bridge for android yet? If not, I was thinking of creating one. I have some python-based games I've been meaning to port to android, and I agree that the right way to do this is through JNI.

I've already managed to get CPython building for android using the NDK (and some build scripts). This is useful because it means that libpython is now being built, and can be linked against by the JNI code.

My original plan was to do a minimal port - just expose the functionality I need through JNI. But if there's a larger project forming here, I'd like to be part of it.

[link]

From: Pete Forman (Jul 29 2010, at 12:39)

Boo is a statically typed variant of Python which sounds similar in intent to Mirah.

[link]

From: John Dougan (Jul 29 2010, at 13:58)

I'm not current as to it's status, but there is a working port of Squeak Smalltalk to Android:

http://news.squeak.org/2010/02/13/squeak-on-android/

[link]

From: Marek Kubica (Jul 29 2010, at 14:47)

I have also done some research because I, erm, dislike Java to put it in friendly terms. I usually use dynamic languages and wanted to go the same path on Android.

On Android there are two ways for language implementations: Native (CPython) or in Java (Jython). Native has the problem of communication with the Android APIs but most dynamic language implementations on the JVM rely on reflection and reflection is not one of Dalvik's strong points.

So I needed something that does not need reflection. Scala fit this requirement and I think also Fantom. But Fantom, while not bad is currently far to obscure and I needed to practice my Scala skills.

Why? Scala is a statically typed language and compiles down to pretty static bytecode which can be compared to plain Java performance. The only downside is that it depends on the Scala library. This issue can be (partly) solved using Proguard, which shakes the bytecode and JARs until they only contain what is neccessary to run the program. My widget is about 200 kB of code, which is not exactly tiny but I think I can live with that, especially when the reward is keeping my sanity.

This works rather well and there is a SBT (Scala build system) Plugin that generates an Android skeleton that you can use with your favorite editor/IDE and hack away.

The nice thing is that Scala itself doesn't need *any* changes at all. I just told it to use Scala 2.8 and it worked.

[link]

From: PJ Eby (Jul 29 2010, at 15:10)

JCC is a code generator that creates C++ bridge code to make Java classes usable from Python:

http://pypi.python.org/pypi/JCC/

And, with a little extra work, it even lets you extend Java classes in Python.

I'm curious to see how well it would work on Android.

[link]

From: mah (Jul 29 2010, at 16:38)

how about coffeescript.

"it compiles into clean JavaScript (the good parts) that can use existing JavaScript libraries seamlessly, and passes through JSLint without warnings. The compiled output is pretty-printed and quite readable".

it is a leaner, and cleaner syntax than javascript,and runs on V8 which is included on andriod

http://jashkenas.github.com/coffee-script/

[link]

From: Tom Rothamel (Jul 29 2010, at 23:10)

For lack of a better place,

http://code.google.com/p/android-jni-cpython/

is a project I started to upload code that shows how one can use cpython via JNI from an android app. I still need to write some documentation explaining how things work. And add more error handling, a better api, cleaner code...

I don't have time right now to turn this into a full wrapping of the Android API, so for now, I'll probably just wrap the functions I need, by hand. JCC is really interesting, though - if someone wants to run it against the android API, that could be very interesting.

[link]

From: John Cowan (Jul 30 2010, at 04:27)

Cedric:

> Fewer lines of code is not ambiguously a good thing.

Actually, it is; it's been known for decades that cost per LOC, as well as bug density per LOC, is roughly constant no matter what language you use. Indeed, it was that single fact that drove the transition from assembly language to Fortran and Cobol in application programming.

> A few counter examples include code that is so terse that it's unreadable (looking at you, Perl)

All in what you are used to. I can read Perl fine, but I find APL unreadable, though APL has worse problems than unreadability.

> and code that removes critical information, such as types, thereby preventing tools such as compilers

ML and Haskell are statically typed programming languages in which type declarations are fairly rare, because compilers can infer types nicely. Java is deliberately not like that: it is, frankly, dumbed down. Java 5 does just enough type inferencing around generics to prevent a peasant revolt.

> or refactoring IDE's from being able to reason about your code.

The refactoring IDE was in fact first developed for Smalltalk, a completely dynamically typed language.

> Tim, I'm curious: have you had to work recently on projects over 100,000 lines of code in Python and Ruby with a team of 10+ people all sharing pieces of that code?

100 KLOC of Python is a lot bigger project than 100 KLOC of Java, not only because Python has less boilerplate, but because it takes advantage of higher-order constructs (though it too is dumbed down in some ways).

[link]

From: Cedric (Jul 30 2010, at 09:48)

John,

I suspect the study about LOC that you are referring to is a few decades old and it was done on languages of that time. Fourth generation languages today are much more expressive and they are the reason why I think that "fewer code lines is not always unambiguously a good thing".

Statically typed languages with type inferences provide the best of both worlds, no argument there. But we are talking about Python and Ruby.

Smalltalk's IDE pioneered refactoring, not automatic refactoring. A lot of the refactorings it performed required human assistance, which should come as no surprise since some refactorings are provably impossible to automate with dynamically typed languages (for an example: http://beust.com/weblog/2006/10/01/dynamic-language-refactoring-ide-pick-one ).

[link]

From: Dan Haffey (Jul 30 2010, at 09:51)

JPype may be of some use in this context: http://jpype.sourceforge.net/

[link]

From: Will Emerson (Aug 01 2010, at 11:57)

Not sure if it fits your requirements but have you checked out Rhodes(http://www.rhomobile.com)? It allows you to write code in ruby and then compile it to iPhone, Android, Blackberry. Looks very interesting.

[link]

From: Antonio (Aug 02 2010, at 05:14)

And what about creating a virutal machine so that people can run stuff on top of it independent of the language? Oh, well, this rings a bell, doesn't it?

[link]

From: Maxx Daymon (Aug 04 2010, at 00:24)

MonoDroid is also coming soon (theoretically August), spurred along by Apple's section 3.3.1. It appears to have some serious effort being put into it as well.

A teaser: http://yfrog.com/mw4eop

[link]

From: Agatheb (Aug 04 2010, at 11:14)

Symbian had had a pretty decent Python support http://wiki.opensource.nokia.com/projects/PyS60

*Very* good to prototype but maybe not that good to make stable commercialized products.

[link]

From: Carlb (Aug 05 2010, at 02:03)

Hello Tim I haven't commented here in a while but have to get my 2 Cents in on this thread.

Yeah of course, you need to do something for the Folks who feel unhappy with Java, period.

My strongly condensed thoughts: Javascript can be used like Lisp, Google already has a very heavy investment going into Javascript with V8, Chrome etc. This is one fundamental direction to go, along the way you can also catch a lot of ruby enthusiasts. (note: is wasen't Ruby as such that made it so popular, it was Rails .. think about it).

You may also want to think about possible synergies with Native Client.

If there was a decent Lisp based industrial strenght developement environment I would use it, and so would of others from the Ruby fraction. Intially Javascript was intended to be a different kind of language, check out douglas Crockford on it, if you haven't already done so.

[link]

From: Andrew (Aug 06 2010, at 02:20)

I am mostly using Haskell and search for a way to build locally running aps for android -- same many others.

In the discussion I did not find a mention of the O'Caml to javascript compiler; it is described as running and with a decent interface to APIs. anybody experience with this?

The efforts to have haskell compile to VM or javascript seem to have petered out; I had no luck with them so far. The idea to replace the backend of the York haskell compiler reported some success in 2009, but nothing since.

[link]

From: Bill Seitz (Aug 11 2010, at 06:58)

I think non-Java languages become even more important as Android spreads to larger devices like tablets.

[link]

author · Dad
colophon · rights
picture of the day
July 28, 2010
· Technology (90 fragments)
· · Android (64 more)
· · Dynamic Languages (45 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.

I’m on Mastodon!