|Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.|
Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.
It's true that you have the ability to add anything to the phone.
There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.
They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform
Choice is good.
And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.
> So having lua on my system would be more or less pointless as I don't use it myself.
Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.
Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.
The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known target.
The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.
As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).
But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).
That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash.
I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa.
Bryan Larsen adds:
For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.
Factors to Consider
- How popular is it? The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
- How big is the run time environment? This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
- Is it easy to learn? Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
- How advanced is it? We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
- Does it have bindings to GTK2, OpenMoko-libs and D-BUS? These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
- How does it perform? Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
- Is it embeddable? Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
- What major applications of interest are available in the language and would be useful on OpenMoko?
Warning: opinions ahead
- Lua is a moderately popular scripting language popular in video games and in Brazil.
- It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus.
- Lua has a simple syntax and is easy to learn.
- It has first class closures. A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides a basic metaprogramming ability. [metalua provides full metaprogramming, if such extremes are needed.
- Bindings are available for GTK2.
- Performance is very similar to Python or Perl
- It is very easy to embed.
- Python is an extremely popular scripting language.
- By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
- Designed as an educational language, it is easy to learn.
- It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
- Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
- Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
- Python can be embedded, although not trivially.
- OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
- Ruby is a popular scripting language.
- Size is unknown, although comparable to Python, I suspect.
- Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
- It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
- Bindings are available for GTK2 and D-BUS.
- Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.
- Perl is a very popular scripting language, although that popularity appears to be waning.
- Sizewise, it is likely to be a little bit smaller than Python or Ruby.
- It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
- Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
- Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.
BASH / Shell scripts
- already included, useful for most cases - example
- Shell is a very popular scripting language.
- There will be a shell of some form available on OpenMoko, therefore it is "free".
- Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
- Shell is a full language, but can hardly be compared to languages designed monolithically. :)
- D-BUS is usable from the command line. GTK2 may be used via gtk-server.
- already included, very powerful - example
- An incomplete set of bindings for GTK2 are available here.. gtk-server may be used instead if those bindings are insufficient.
- There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
- Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
- Lisp syntax is very simple, and hated by many. :)
- Modern lisp variants are more "powerful" than every other language listed here.
- GTK2 and D-BUS bindings are available
- Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons.
- A full J2ME implementation takes about 2 Megabytes of space. (reading in between the lines here. I could be very wrong). However since it's likely to be included in the phone for other reasons it can be considered "free".
- Java is very C-like.
- Java is not a scripting language and doesn't support advanced scripting language features.
- libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
- JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
- If a JVM is on the phone, then JRuby is "free".
- JRuby can use the Java bindings to GTK2.
If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.
If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.
JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.
--Bryan Larsen 21:44, 3 April 2007 (CEST)