
 An Android Side Project - wglb
http://www.tbray.org/ongoing/When/201x/2010/04/11/Other-Android-Languages
======
andr
"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.

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

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

~~~
dagw
The Adam has one other huge potential selling point in its pixelQi screen. If
pixelQi works as advertised and people get a chance to experience it, I can
see that swinging it for the Adam for people who primarily want a tablet to
read text on.

------
Estragon

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

~~~
nl
"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>

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

------
brown9-2
_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.

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

~~~
gte910h
Try flash CS5. It has support.

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

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

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

~~~
ibsulon
I'm curious... how would you have developed a schema for S-Expressions without
it ending up just as verbose? What do you lose? End tags?

<http://www.agentsheets.com/lisp/XMLisp/> as an example of what XML in lisp
would look like, and I can't say it's much of an improvement. Further, end
tags make human debugging much easier.

~~~
wingo
There are many possibilities. SXML is the one I use.

You need to use a semi-structured editor, like paredit on emacs, to get all of
the advantages, though. Otherwise as you mention you'll be grovelling for the
closing paren, when the machine could have maintained the balance from the
beginning.

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

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

~~~
mclin
I think you can't use native menus right now:
[http://developer.appcelerator.com/question/9731/android-
bott...](http://developer.appcelerator.com/question/9731/android-bottom-menu)

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

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

