An Android Side Project

http://www.tbray.org/ongoing/When/201x/2010/04/11/Other-Android-Languages

by wglb • 16 years ago

102 34 16 years ago

lsb• 16 years ago

In summary, Tim Bray is looking to write Android apps in Ruby or another dynamic language.

It's interesting that someone who worked on the XML spec says that he's "slipped into the camp of those who find the Java language verbose and rigid and overly ceremonious".

div• 16 years ago

Why exactly do you find that interesting, or are you just getting in a potshot at xml while you're at it ? :)

bmelton2• 16 years ago

Perhaps I don't have the appropriate history, but XML did a fine job of doing what it was supposed to do. I don't know of any other method (at the time of XML's inception) that allowed you to throw arbitrary fields into a file, describe them all, describe their relationships and reasonably convey to the user what you can do with all of it, and be human readable and be machine readable all at the same time.

Perhaps I'm an idiot and JSON's a lot older than I'm giving it credit for, but I thought XML was (and still is) a decent tool. I also don't think that it's overly verbose given how descriptive it can be.

mseebach• 16 years ago

Before XML, you either had completely plain text-files, like INIs, or even JSON today. That's great for humanly editable files, but defining complex types in such files is a bit arbitrary, and there's room for lots of ambiguity. What are the valid fields and values?

On the other hand, binary file-types usually mapped to C structs. This results in files that are near impossible to read or write if you don't have access to those structs. It was also vulnerable to encoding issues like bit-order.

XML bridged those extremes. When using XSD etc. correctly it's possible (in theory) to validate locally if a given file will be read and understood by any and all other software implementing the same standard. It removes (in theory) the ambiguity of the plain-text formats, while still resulting in an output that's (in theory) immediately readable and editable by a human with no external references.

The promise of XML is to replace the big, proprietary binary files, not to be the end-all be-all of textually encoded data. Small, simple RESTful webservices has no need for XML. Big, complicated ones might not, but once you've coded up against an advanced WSDL API, and the generated stubs just worked, complete with types and pre-wire validation, it's not hard to see the value.

moron4hire2• 16 years ago

Lisp S-Expressions would have worked, and they've been around forever. JSON is basically a more-verbose sort of S-Expression.

bitwize• 16 years ago

Bray has been an opponent of the extraneity and cruft that has accreted around XML and its satellite formats; for example, promoting his own XML-RPC over the competing (and considerably more complicated) SOAP.

nailer• 16 years ago

Awesome. The Android Scripting Environment is very limited in what it can do. Native support support for Python and Ruby would help those of us who love to Make Stuff but don't have the patience for Java.

gte910h2• 16 years ago

Try flash CS5. It has support.

andr• 16 years ago

"If what you produce sucks, the word will get around quick; having used the official Android toolchain won’t save you."

This is the biggest weakness in Apple's argument. Watch crowds of developers trying to create their first 3D engine to replace Unity3D.

Oh, how I long for an Android tablet on par with the iPad.

bmelton2• 16 years ago

For as much as I like my iPad, I agree with you 100%. I'm not crazy about the hardware as much as I am the OS (which is basically just iphone OS), and I know that with Apple's developer restrictions (and that I don't know Objective C, and probably won't bother to learn it because of Apple's developer restrictions) it'll never be more than a toy for me until somebody builds an app that makes it an appliance. As of right now, Epicurious comes closest to this goal, of transforming it into a purpose-built piece of hardware.

The obvious counter-argument to this is to build apps as HTML(4 or 5) for the iPad, and then they should "just work" whenever an Android competitor comes out, but for now, the iPad's lack of slide animations in Safari bugs the living hell out of me.

dagw2• 16 years ago

regarding your last question and depending on your definition of "on par", my bet is currently on www.notionink.com.

flogic• 16 years ago

I really hope the Adam succeeds. It really looks like a neat device.

tcdent• 16 years ago

The Adam is really gong to sink or swim because of it's UI, which is (AFAIK) non-existent, or just basic Android, at this point.

Estragon2• 16 years ago

  Also, in theory you ought to be able to use the Android NDK
  to get the native C versions of Ruby and/or Python going. 
  It’d be a slog, but the idea doesn’t seem insane.

I'd be really interested to hear about anyone doing this. Seems like you pay a heavy price for dynamicity on Dalvik, because introspection is expensive.

bad_user• 16 years ago

> Seems like you pay a heavy price for dynamicity on Dalvik, because introspection is expensive

Citations?

On Android it seems to me that all APIs are running on top of Dalvik, so to use other interpreters (outside of Dalvik) means you have to pay the price for IPC calls (coupled with an interpreter that isn't optimized for mobiles).

Estragon2• 16 years ago

Search for clojure on android.

nl• 16 years ago

"all APIs are running on top of Dalvik"

No, the NDK (Native Development Kit) allows you to bypass Dalvik for some APIs - OpenGL ES, math, compression etc. The complete list is on http://developer.android.com/sdk/ndk/index.html

barrkel2• 16 years ago

FWIW, native Python already runs on my Nexus One, from the ASE - http://code.google.com/p/android-scripting/

It uses RPC to do Android-native calls though.

brown9-2• 16 years ago

In practical terms, if you want it to look-and-feel like an Android app, you have to use the Android SDK; but what language you generate those bytecodes and method calls with, and how you compile it, well, why should anyone care?

I think this is the perfect summation of the entire issue here.

mclin2• 16 years ago

Somehow I predict Titanium's Android support to improve greatly once they lose their primary mobile platform. Then we could write Android apps in JavaScript (yay!)

Currently it's kind of a tack one.

ryanhuff• 16 years ago

Can you expand on your Titanium Android comment? I am about to embark on building an android app, and was leaning toward using Titanium, so would appreciate hearing about any roadblocks I might encounter.

gte910h2• 16 years ago

From my experience, it's still incomplete. They aren't doing pretty basic things like "show controls on your movie player" etc.

mclin2• 16 years ago

I think you can't use native menus right now: http://developer.appcelerator.com/question/9731/android-bott...

Not sure about back button too. I'm sure it's all in flux.

aphyr• 16 years ago

I'd be happier if Titanium started up in under under five minutes. Something is seriously troubled in their linux version.

vito• 16 years ago

Nice timing; I was actually just playing with Duby + Android last night, it's just about perfect. Just be sure to get the latest git of Duby, and not the one in rubygems.

Here's a token Hello, world! app: http://pastie.org/915727

To get it going all you need to do is edit your build.xml to add a new compile target before the </project> (thanks to technomancy for this):

    <target name="compile" depends="-resource-src, -aidl"
            description="Compiles project's .duby files into .class files">
      <exec executable="dubyc" dir="src">
        <env key="CLASSPATH" file="${sdk.dir}/platforms/android-7/android.jar" />
        <arg value="-d" />
        <arg value="../bin/classes/" />
        <arg value="." />
      </exec>
    </target>

You may want to change android-7 to whatever platform you're on (and make sure sdk.dir is correct, it should be in your local.properties).

mufumbo• 16 years ago

I think that the only problem of his code is that it should be: Map<String, List<Person>> buf = new HashMap<String, ArrayList<Person>>();

You probably don't really write that if you use eclipse.

I guess that writing articles and articles about how java is bad and ruby is much better doesn't really deliver apps. By the time all these frameworks are written it will be already outdated and the person who wrote it loosed the time to the android market.

sreque• 16 years ago

Funnily enough, your code won't compile. The generic signature of your hash map is incompatible with the signature of your variable declaration. You'll instead get a verbose error message like the following:

Test.java:6: incompatible types found : java.util.HashMap<java.lang.String,java.util.ArrayList<java.lang.String>> required: java.util.Map<java.lang.String,java.util.List<java.lang.String>> Map<String, List<String>> buf = new HashMap<String, ArrayList<String>>();

There really are productivity wins to using some of these newer languages, but you'll never learn that by just whining about their existence.

pkulak• 16 years ago

Right now I'd say that Apple has fantastic library support behind a language that's a huge pain to use. Android has weaker libraries, but uses a language that arguably a bit nicer to use. If Google could put out some official support for something like Ruby it could be a huge boon to the app market.

An Android Side Project

Related Stories