Wishlist/BuiltInScriptingLanguage

From Openmoko

Revision as of 09:06, 14 September 2007 by Sin (Talk | contribs)

Jump to: navigation, search
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.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.


Contents

Feature matrix

Since there are a lot of options, the main features of the candidates should be collected in a matrix. Fill in and add to this if possible.

Language Current Status Disk Footprint Memory Footprint Compilable Scriptable
Java ? ? ? JIT / gcj ?
Python ? ? ? JIT(Psyco) / Pyrex Y
C#/mono ? ? ? JIT N
Perl ? ? ? ? ?
Haskell ? ? ? Y Y
LUA Mature/Active Light Light JIT(Lua-JIT) Y
Ruby ? ? ? ? ?

Discussion

There was a discussion on the mailing list about choosing a built-in scripting language.


As expressed by Corey:

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.

Derek Pressnall also expressed it well:

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

[and Ben Burdette:]

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:

It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!

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

  1. 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.
  2. 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.
  3. 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?
  4. 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!
  5. 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.
  6. 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.
  7. 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.
  8. What major applications of interest are available in the language and would be useful on OpenMoko?

The Languages (already included)

BASH / Shell scripts

  1. already included, useful for most cases - example
  2. Shell is a very popular scripting language.
  3. There will be a shell of some form available on OpenMoko, therefore it is "free".
  4. Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
  5. Shell is a full language, but can hardly be compared to languages designed monolithically.  :)
  6. D-BUS is usable from the command line. GTK2 may be used via gtk-server.

AWK

  1. already included, very powerful - example

SED

  1. already included, useful together with bash / awk example1,example2

Javascript

  1. Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
  2. Javascript will be available on whichever web browser is included in the project, therefore it is "free".
  3. Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
  4. Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
  5. An incomplete set of bindings for GTK2 are available here.. gtk-server may be used instead if those bindings are insufficient.


The Languages (not included)

Warning: opinions ahead

Lua

  1. Lua is a moderately popular scripting language popular in video games and in Brazil. A good intro is this recent LJ article
  2. It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
  3. Lua has a simple syntax and is easy to learn. Reference the online book.
  4. It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. metalua provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
  5. Bindings are available for GTK2. Reference the Lua Libraries and Bindings page. Specifically the Lua-gtk project
  6. Performance are substantially better than Python's or Perl's.
  7. It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
  8. Example Implementation for Symbian.

Python

  1. Python is an extremely popular scripting language.
  2. 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.
  3. Designed as an educational language, it is easy to learn.
  4. It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
  5. Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
  6. Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
  7. By using Pyrex/PyInline/Boost/SWIG/Weave, taxing algorithms can get C-like performance. Nice benchmarks here. Shed Skin also looks promising.
  8. Python can be embedded, although not trivially. DePython (footprint <200k) is proof of concept, but currently unmaintained.
  9. Example implementation for Symbian. The runtime environment is under 1MB (i think ~700KB), with a footprint of about 150kb. There are well working programs for it like EasyEdit
  10. OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
  11. Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
  12. Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as this.
  13. Jython would make it almost 'free', but it's slower and not identical to CPython.

Ruby

  1. Ruby is a popular scripting language.
  2. Size is unknown, although comparable to Python, I suspect.
  3. 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.
  4. It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
  5. Bindings are available for GTK2 and D-BUS.
  6. Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

Perl

  1. Perl is an extremely popular scripting language.
  2. Sizewise, it is likely to be a little bit smaller than Python or Ruby.
  3. 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.
  4. Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
  5. Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
  6. Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

Lisp/Scheme/Guile

  1. 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.
  2. Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
  3. Lisp syntax is very simple, and hated by many.  :)
  4. Modern lisp variants are more "powerful" than every other language listed here.
  5. GTK2 and D-BUS bindings are available

Java

  1. 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. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
  2. 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". Also, there's the very small JamVM as an alternative.
  3. Java is very C-like.
  4. Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
  5. libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
  6. If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
  7. The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
  8. The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
  9. JavaFX is a Multimedia based scripting language that adds wow to devices
  10. The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
  11. Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

JRuby

  1. 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.
  2. If a JVM is on the phone, then JRuby is "free".
  3. JRuby can use the Java bindings to GTK2.

Mono/C#

  1. Not a scripting language, but offers garbage collection and other nice features.
  2. Already used in a similar setup on Nokia 770/800.
  3. Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see here).
  4. Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

Summary

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.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

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)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --Dmitri Hrapof 18 April 2007

By looking at the GNOME Mobile & Embedded Initiative page, I see that there is a picture of the Neo1973 and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --Nakedible 12:30, 30 April 2007 (CEST)

Personal tools
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.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.


Feature matrix

Since there are a lot of options, the main features of the candidates should be collected in a matrix. Fill in and add to this if possible.

Language Current Status Disk Footprint Memory Footprint Compilable Scriptable
Java ? ? ? JIT / gcj ?
Python ? ? ? JIT(Psyco) / Pyrex Y
C#/mono ? ? ? JIT N
Perl ? ? ? ? ?
Haskell ? ? ? Y Y
LUA Mature/Active Light Light JIT(Lua-JIT) Y
Ruby ? ? ? ? ?

Discussion

There was a discussion on the mailing list about choosing a built-in scripting language.


As expressed by Corey:

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.

Derek Pressnall also expressed it well:

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

[and Ben Burdette:]

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:

It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!

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

  1. 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.
  2. 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.
  3. 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?
  4. 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!
  5. 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.
  6. 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.
  7. 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.
  8. What major applications of interest are available in the language and would be useful on OpenMoko?

The Languages (already included)

BASH / Shell scripts

  1. already included, useful for most cases - example
  2. Shell is a very popular scripting language.
  3. There will be a shell of some form available on OpenMoko, therefore it is "free".
  4. Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
  5. Shell is a full language, but can hardly be compared to languages designed monolithically.  :)
  6. D-BUS is usable from the command line. GTK2 may be used via gtk-server.

AWK

  1. already included, very powerful - example

SED

  1. already included, useful together with bash / awk example1,example2

Javascript

  1. Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
  2. Javascript will be available on whichever web browser is included in the project, therefore it is "free".
  3. Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
  4. Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
  5. An incomplete set of bindings for GTK2 are available here.. gtk-server may be used instead if those bindings are insufficient.


The Languages (not included)

Warning: opinions ahead

Lua

  1. Lua is a moderately popular scripting language popular in video games and in Brazil. A good intro is this recent LJ article
  2. It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
  3. Lua has a simple syntax and is easy to learn. Reference the online book.
  4. It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. metalua provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
  5. Bindings are available for GTK2. Reference the Lua Libraries and Bindings page. Specifically the Lua-gtk project
  6. Performance are substantially better than Python's or Perl's.
  7. It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
  8. Example Implementation for Symbian.

Python

  1. Python is an extremely popular scripting language.
  2. 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.
  3. Designed as an educational language, it is easy to learn.
  4. It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
  5. Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
  6. Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
  7. By using Pyrex/PyInline/Boost/SWIG/Weave, taxing algorithms can get C-like performance. Nice benchmarks here. Shed Skin also looks promising.
  8. Python can be embedded, although not trivially. DePython (footprint <200k) is proof of concept, but currently unmaintained.
  9. Example implementation for Symbian. The runtime environment is under 1MB (i think ~700KB), with a footprint of about 150kb. There are well working programs for it like EasyEdit
  10. OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
  11. Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
  12. Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as this.
  13. Jython would make it almost 'free', but it's slower and not identical to CPython.

Ruby

  1. Ruby is a popular scripting language.
  2. Size is unknown, although comparable to Python, I suspect.
  3. 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.
  4. It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
  5. Bindings are available for GTK2 and D-BUS.
  6. Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

Perl

  1. Perl is an extremely popular scripting language.
  2. Sizewise, it is likely to be a little bit smaller than Python or Ruby.
  3. 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.
  4. Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
  5. Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
  6. Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

Lisp/Scheme/Guile

  1. 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.
  2. Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
  3. Lisp syntax is very simple, and hated by many.  :)
  4. Modern lisp variants are more "powerful" than every other language listed here.
  5. GTK2 and D-BUS bindings are available

Java

  1. 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. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
  2. 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". Also, there's the very small JamVM as an alternative.
  3. Java is very C-like.
  4. Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
  5. libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
  6. If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
  7. The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
  8. The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
  9. JavaFX is a Multimedia based scripting language that adds wow to devices
  10. The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
  11. Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

JRuby

  1. 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.
  2. If a JVM is on the phone, then JRuby is "free".
  3. JRuby can use the Java bindings to GTK2.

Mono/C#

  1. Not a scripting language, but offers garbage collection and other nice features.
  2. Already used in a similar setup on Nokia 770/800.
  3. Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see here).
  4. Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

Summary

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.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

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)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --Dmitri Hrapof 18 April 2007

By looking at the GNOME Mobile & Embedded Initiative page, I see that there is a picture of the Neo1973 and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --Nakedible 12:30, 30 April 2007 (CEST)