Introducing the Android Scripting Environment [LWN.net]

Google has announced a new Android Scripting Environment. "The Android Scripting Environment (ASE) brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device. These scripts have access to many of the APIs available to full-fledged Android applications, but with a greatly simplified interface that makes it easy to: * Handle intents * Start activities * Make phone calls * Send text messages * Scan bar codes * Poll location and sensor data * Use text-to-speech (TTS) * And more". (Thanks to Francisco Borges).

to post comments

Misread

Posted Jun 11, 2009 22:17 UTC (Thu) by dfsmith (guest, #20302) [Link] (10 responses)

I first read the headline as "Android Sculpting Environment" and thought, "Cool; they integrated the accelerometers with SketchUp". It's the kind of thing they'd do.

Misread

Posted Jun 11, 2009 22:52 UTC (Thu) by sbergman27 (guest, #10767) [Link] (9 responses)

"""
It's the kind of thing they'd do.
"""

No. That's not really what they are doing here.

Those who do not understand unix are doomed to reinvent it, poorly.
Those who do not understand Java are doomed to reinvent it, poorly.

Google is in a position of trying to reinvent both at the same time... poorly. Google is a younger, hipper version of Microsoft crafting their own rendition of NT.

Misread

Posted Jun 12, 2009 1:14 UTC (Fri) by pawpawyoung (guest, #19830) [Link]

Great comment for Google and M$.

Misread

Posted Jun 12, 2009 1:42 UTC (Fri) by mikov (guest, #33179) [Link] (3 responses)

Although I don't necessarily agree 100%, I have to say that this was a very very insightful post.

Why don't I agree a 100%? I used to work on a project to get Java applications usable for a desktop, mainly by improving startup speed and real-time deterministic garbage collecton, but also improving sharing between, processes, etc. We finally concluded that Java is broken in this respect and cannot be fixed without incompatible changes in the language and the JVM. The changes would not be dramatic, most code would probably still run, perhaps with small fixes, but it would definitely not be Java (tm) anymore.

So, I guess this is what Google has done. Java's problems, while merely annoying on a desktop, cannot be tolerated on a phone. On the other hand, for real apps on a new smart device, silly toys like Java ME are no longer applicable.

Same goes for Linux/Unix actually. Linux, as an OS, not just a kernel, has some problems which cannot be fixed compatibly. They are merely annoying on a desktop or server, but on a specialized device?? If Google wanted to deliver a quality product fast, all they had to do is fix the problems and call it "not-Linux". Makes sense to me.

Specifics

Posted Jun 12, 2009 3:46 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

Could you be more specific about the issues you found with Java and Linux/Unix?

Specifics

Posted Jun 12, 2009 4:34 UTC (Fri) by mikov (guest, #33179) [Link] (1 responses)

If you mean issues with Java _on_ Linux - IIRC there wasn't anything that was Linux specific.

On the other hand, if you mean issues issues with Java, and separately issues with Linux:

I can't readily remember details off the top of my head, but they were quite technical. Generally you just can't make Java load fast without breaking it. The very nature of the loading process, with the dynamic class loaders, defineClass(), reflection, etc, makes it impossible. Plus, the standard library is quite big but intertwined, so you just can't avoid loading most of it even for trivial apps. And then you can't optimize Java without lots of memory, and you can't optimize at all if you want to share code between running processes, let alone garbage collect generated code. Plus, with that much memory you absolutely need an excellent realtime GC, but Sun Java doesn't have one, and no free project has one either. And so on.

On the other hand, Java as a language isn't bad (albeit primitive and verbose), and the library is quite good too (at least compared to others). So, it is natural to want to "fix it", while preserving most of the good things.

About the "issues with Linux" ... Where do I begin? We read about this everyday here. POSIX is a mess. X is a complete mess. 3D is a mess. NFS ... let's not even go there. The situation with the sound is a mess. GUI programming is a mess (see the discussions about Chrome for Linux - while on that subject, sandboxing is a mess). ELF shared libraries are a mess. Plug&Play device driver loading is a mess.

Don't get me wrong though. I am not saying that it is worse than other OS-es, or that a "mess" means "piece of crap". In fact this constant state of flux makes it fun, and there a millions of creative solutions to the problems.

I am just saying, there are plenty of things that one might be tempted to throw away and redesign from scratch, given the opportunity.

Specifics

Posted Jun 12, 2009 9:56 UTC (Fri) by dgm (subscriber, #49227) [Link]

Yours are very interesting opinions. I would love to see them elaborated. Maybe you can write some articles? Last time I checked LWN was accepting contributors, is it still true?

Misread

Posted Jun 12, 2009 18:02 UTC (Fri) by man_ls (guest, #15091) [Link] (3 responses)

Aren't they rather reinventing something like AppleScript or DCOP? Somehow these two have never fulfilled their respective promises. I don't really know why -- I have used both and they sort-of worked, but were never as cool as promised. At least the Unix Shell is a silent workhorse, and even (*urgh*) DOS has more uses.

Misread

Posted Jun 16, 2009 17:17 UTC (Tue) by pboddie (guest, #50784) [Link] (2 responses)

DCOP? To paraphrase an earlier remark: those who do not understand CORBA are doomed to reinvent it, poorly.

I don't really advocate application automation - it's better to expose the underlying services used by an application separately, rather than have a graphical application manipulate data on one's behalf, even if it isn't opening and closing dialogues while doing so - but my experiences with DCOP suggest that the technology is either so awkward when exposing proper components that no-one bothers to do so, or the support for what everyone used to be called "distributed objects" (which need not involve a network connection) just isn't there.

Of course there's D-BUS now, which appears popular in various projects (the Free Smartphone stuff, for example) but, from what I've heard, has about as much usability appeal as DCOP.

Misread

Posted Jun 16, 2009 22:20 UTC (Tue) by man_ls (guest, #15091) [Link] (1 responses)

CORBA is something to reinvent? I thought that object-oriented interchange had gone the way of the dodo after 2000. True, GNOME makes good use of it, but the world doesn't seem to care anymore. It has not held its promise. If DCOP is the same stuff now I understand why it has failed too.

That is not the same as structured text interchange, which is widely used and accepted (in the form of XML mostly). Anyway you are right IMHO that exposing the underlying services (e.g. as a command-line interface) is a more unix-y way of doing things.

Misread

Posted Jun 17, 2009 9:42 UTC (Wed) by pboddie (guest, #50784) [Link]

If I remember correctly, my main problem with D-Bus and DCOP when compared to COM or CORBA is that they really only provide a messaging infrastructure exposing endpoints in a REST-like way (the "/org/kde/documents/4352" type stuff in the D-Bus FAQ), also reminiscent of Plan 9 and, for those with a recollection of obscure proprietary technologies, Computer Concepts' Impulse: applications provide a virtual filesystem where the files or resources are part files, part objects.

All of the above is a nice idea - it'd be more intriguing if you could actually use the virtual files/resources with traditional UNIX tools - but there can be irritating limitations: all such resources have to be named explicitly, occupying parts of the namespace, and yet there are activities where such explicit naming is superfluous, such as in an automation interface for Konqueror which I attempted to write (and which worked, for a time) where one generally doesn't want every node in an XML document to exist as a named entity in some namespace.

Of course, if one is publishing objects in some way or another, there will always be some need for identifiers for each of the objects, but the policy difference around naming between DCOP and CORBA makes any use of the former a chore for activities like those described above. The result is that given the choice of working around such issues and still providing a "rich" interface, or settling for a simpler interface, developers are likely to choose the latter with bizarre consequences: as far as I recall, KMail exposes a simple interface which is stateful, having the notion of "the current folder", and this is obviously inferior to any interface where one can merely acquire a reference to a folder and use it indefinitely.

Anyway, this rant is over for now. Maybe I'll pick it up again if I have to do anything with D-Bus in the near future. ;-)

Introducing the Android Scripting Environment

Posted Jun 12, 2009 4:36 UTC (Fri) by leemgs (guest, #24528) [Link]

I like support of Lua , Luby on ASE in private.
*ASE Application & DOc -> http://code.google.com/p/android-scripting
*ASE Google Groups -> : http://groups.google.com/group/android-scripting

Python on smartphones: Android, iPhone, Symbian S60

Posted Jun 12, 2009 7:05 UTC (Fri) by Cato (guest, #7643) [Link]

One of the nice things now is that you can run a decent language like Python on almost any smartphone, or at least Android, iPhone and Symbian S60. The phone APIs will differ a lot, but on S60 you get the full Python libraries - so something like downloading to a specific pathname from the web is really just 2 lines of code. This is a far cry from the days of proprietary scripting or C code on early smartphones from Symbian and Palm, and it's really nice to be able to re-use language skills across platforms.

I actually know Perl best, but I don't see much prospect of it being supported across a lot of smartphones, whereas Python is actually supported by Google and Nokia.