An Android Side Project(tbray.org)
tbray.org
An Android Side Project
http://www.tbray.org/ongoing/When/201x/2010/04/11/Other-Android-Languages
9 comments
regarding your last question and depending on your definition of "on par", my bet is currently on www.notionink.com.
I really hope the Adam succeeds. It really looks like a neat device.
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.
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.
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.
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.
> 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).
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).
"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
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
Search for clojure on android.
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.
It uses RPC to do Android-native calls though.
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):
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>
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.
I think this is the perfect summation of the entire issue here.
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".
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".
Why exactly do you find that interesting, or are you just getting in a potshot at xml while you're at it ? :)
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.
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.
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.
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.
Lisp S-Expressions would have worked, and they've been around forever. JSON is basically a more-verbose sort of S-Expression.
Whoever does not understand Lisp, is doomed to reinvent it.
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.
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.
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.
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.
Sexprs on their own are not enough - I think you're confusing surface syntax for the whole semantic lot. XML's namespaces, for example, let different applications mark up the XML without risk of clobbering one another. JSON isn't really comparable to XML at all - it's much weaker.
But namespaces are just more data. Namespaces, in my experience, have just turned into a hurdle that requires a bunch of needless element decoration to get it to play nice with XPath. The only place I know of where there is great confusion over what "XML" document you're processing is a browser trying to decide what type of document it's working with, i.e. all of the various versions of HTML and XHTML. That's not an argument for namespacing, that's an argument against forking markup languages. In every case where I've built XML processing services, I always knew what the purpose of the document was ahead of time.
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.
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.
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.
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.
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.
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.
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.
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.
Currently it's kind of a tack one.
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.
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.
Not sure about back button too. I'm sure it's all in flux.
From my experience, it's still incomplete. They aren't doing pretty basic things like "show controls on your movie player" etc.
[deleted]
I'd be happier if Titanium started up in under under five minutes. Something is seriously troubled in their linux version.
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.
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.