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.

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.

  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.

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

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

It uses RPC to do Android-native calls though.

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>

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

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

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.

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.

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.

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.

Then there's XML Schema. In practice, I doubt few people actually validate documents against an XSD, in the rare cases one actually existed. Have you ever tried writing a reasonable sized XSD? Why are attributes treated differently from elements with a single text node as a child? Why can't I specify that a certain attribute is a prerequisite for another? Why are we specifying document structure and default values at the same time? What safety is type information actually giving me if I have to validate in my consuming service anyway?

I've had to process XML documents that claimed to be of such-and-such standard schema, and it invariably turns out untrue. There's always some 11pm job that fails to validate a doc because the author added an extra attribute or misspelled one you don't care about. Eventually, you just turn validation off and start doing things much more dynamically. I've always had to infer the schema from the document itself, otherwise my apps were too rigid for real-world use.

Someone else mentioned that S-exprs would need an intelligent editor to make writing them more coherent. I personally think the same is true for XML, as reasonably large (i.e. anything beyond tutorial demonstrations) XML documents will have the same problem of guessing what tags are already closed and which order they should be closed in, if only because their openings have scrolled off the top of the screen. Sure, you know you're closing a DIV tag right now, but which one? How long did it take to get decent XML syntax validation? While your Lisp interpreter has been sitting there quietly for the last 60 years. Throw in validation against namespacing and schema, and you still need an intelligent editor either way.

I don't really buy that XML is human readable, either. You don't read a 5000 line XML document, there's nothing to be gained from reading raw XML in that case (even if you have a raw text editor that can handle the file size). XML might have a slight advantage with being easier to demonstrate for new people learning, but once you get into actually using these tools, you don't ever use them in the "human readable/editable" format. That'd be like managing your finances with nothing but text files.

I'm just saying, Lisp was already well understood and parsed by the time XML was invented, and even XML + XSLT isn't even on parity with Lisp. Namespacing and XML Schema just turn out to be conventions that people say they're going to try to adhere to, but never do. Like I said, just like speed limits on roads.

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.

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.

Currently it's kind of a tack one.

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