Wishlist/BuiltInScriptingLanguage

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Python)
(Lisp/Scheme/Guile)
 
(29 intermediate revisions by 11 users not shown)
Line 20: Line 20:
 
! align="center" |Java
 
! align="center" |Java
 
|align="center" |?
 
|align="center" |?
|align="center" |?
+
|align="center" |Medium
|align="center" |?
+
|align="center" |Heavy
|align="center" |JIT / gcj
+
|align="center" |JIT/gcj
|align="center" |?
+
|align="center" |Y (Jython/JRuby/Groovy)
 
|-
 
|-
 
!align="center" |Python
 
!align="center" |Python
|align="center" |?
+
|align="center" |Mature/Active
|align="center" |?
+
|align="center" |Light
|align="center" |?
+
|align="center" |Medium
|align="center" |Pyrex / PyPy JIT
+
|align="center" |Pyrex/RPython
 
|align="center" |Y
 
|align="center" |Y
 
|-style="background: #DDFFDD;"
 
|-style="background: #DDFFDD;"
!align="center" |C#/mono
+
!align="center" |C#/mono/IronPython
|align="center" |?
+
|align="center" |In development
|align="center" |?
+
|align="center" |Heavy
|align="center" |?
+
|align="center" |Heavy
 
|align="center" |JIT
 
|align="center" |JIT
|align="center" |N
+
|align="center" |Y (IronPython)
 
|-
 
|-
 
!align="center" |Perl
 
!align="center" |Perl
 +
|align="center" |Mature
 +
|align="center" |Light
 +
|align="center" |Medium
 
|align="center" |?
 
|align="center" |?
|align="center" |?
+
|align="center" |Y
|align="center" |?
+
|align="center" |?
+
|align="center" |?
+
 
|-style="background: #DDFFDD;"
 
|-style="background: #DDFFDD;"
 
!align="center" |Haskell
 
!align="center" |Haskell
 
|align="center" |?
 
|align="center" |?
|align="center" |?
+
|align="center" |Heavy
|align="center" |?
+
|align="center" |Light
|align="center" |Y
+
|align="center" |Native, JIT and bytecode
 
|align="center" |Y
 
|align="center" |Y
 
|-
 
|-
Line 57: Line 57:
 
|align="center" |Light
 
|align="center" |Light
 
|align="center" |Light
 
|align="center" |Light
|align="center" |JIT(Lua-JIT)
+
|align="center" |N
 
|align="center" |Y
 
|align="center" |Y
 
|-style="background: #DDFFDD;"
 
|-style="background: #DDFFDD;"
 
!align="center" |Ruby
 
!align="center" |Ruby
 
|align="center" |?
 
|align="center" |?
|align="center" |?
+
|align="center" |Light
|align="center" |?
+
|align="center" |Medium
|align="center" |?
+
|align="center" |N
|align="center" |?
+
|align="center" |Y
 
|-
 
|-
 
!align="center" |Scheme
 
!align="center" |Scheme
Line 72: Line 72:
 
|align="center" |Light
 
|align="center" |Light
 
|align="center" |Y
 
|align="center" |Y
 +
|align="center" |Y
 +
|-
 +
!align="center" |Squirrel
 +
|align="center" |Mature/Active
 +
|align="center" |Light
 +
|align="center" |Light
 +
|align="center" |N
 +
|align="center" |Y
 +
|-
 +
!align="center" |[[PHP-GTK]]
 +
|align="center" |Active
 +
|align="center" |Light
 +
|align="center" |Medium
 +
|align="center" |[http://dk.php.net/bcompiler Bytecode]
 
|align="center" |Y
 
|align="center" |Y
 
|}
 
|}
Line 85: Line 99:
 
''It's true that you have the ability to add anything to the phone.''
 
''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.''
+
''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''
 
''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''
Line 93: Line 107:
 
''Choice is good.''
 
''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.''
+
''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.''
 
''> 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.''
+
''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.''
 
''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.''
Line 117: Line 131:
 
''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. ''
 
''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. ''
+
''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:
 
Bryan Larsen adds:
Line 123: Line 137:
 
''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!''
 
''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.
+
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 ==
 
== 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 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.
+
# '''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?
 
# '''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!
 
# '''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.
+
# '''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.
 
# '''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.
+
# '''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?
+
# '''What major applications of interest''' are available in the language and would be useful on Openmoko?
  
 
== The Languages (already included) ==
 
== The Languages (already included) ==
Line 142: Line 156:
 
# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
 
# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
 
# Shell is a very popular scripting language.
 
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
+
# 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 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.  :)
 
# Shell is a full language, but can hardly be compared to languages designed monolithically.  :)
Line 176: Line 190:
 
# 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.  [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.   
 
# 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.  [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.   
 
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page. Specifically the [http://luaforge.net/projects/lua-gtk/ Lua-gtk project]
 
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page. Specifically the [http://luaforge.net/projects/lua-gtk/ Lua-gtk project]
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
+
# Performance is substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
 
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
 
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
 
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.
 
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.
Line 188: Line 202:
 
# Bindings are available for GTK2 and [[D-Bus#Python]].  GTK bindings are part of the Gnome project.
 
# Bindings are available for GTK2 and [[D-Bus#Python]].  GTK bindings are part of the Gnome project.
 
# [[Manually using Bluetooth]] has parts in Python
 
# [[Manually using Bluetooth]] has parts in Python
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko. The PyPy JIT is on it's way.
+
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to Openmoko. The PyPy JIT is on it's way.
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/[http://www.boost.org/libs/python/doc/ Boost]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here]. PyPy already is somewhat usable and [http://mark.dufour.googlepages.com/ Shed Skin] looks promising.
+
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/[http://www.swig.org/ SWIG], hungry algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here]. RPython (PyPy) already is somewhat usable and [http://mark.dufour.googlepages.com/ Shed Skin] looks promising.
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] (footprint <200k) is proof of concept, but currently unmaintained.
+
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] (footprint <200k) is proof of concept, but currently unmaintained. Tinypy may become usable.
# [http://opensource.nokia.com/projects/pythonfors60/ 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 [http://p7.hostingprod.com/@s60freeware.com/s60blog/2006/06/easyedit_a_text_editor_for_the.html EasyEdit]
+
# [http://opensource.nokia.com/projects/pythonfors60/ 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 [http://p7.hostingprod.com/@s60freeware.com/s60blog/2006/06/easyedit_a_text_editor_for_the.html EasyEdit]
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
+
# OLPC uses Python heavily and may produce applications suitable for porting to Openmoko
 
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
 
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
+
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this media player].
 
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.
 
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.
  
Line 217: Line 231:
 
=== Lisp/Scheme/Guile ===
 
=== Lisp/Scheme/Guile ===
  
# 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.
+
# 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 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.  :)
 
# Lisp syntax is very simple, and hated by many.  :)
 
# Modern lisp variants are more "powerful" than every other language listed here.
 
# Modern lisp variants are more "powerful" than every other language listed here.
 
# GTK2 and D-BUS bindings are available
 
# GTK2 and D-BUS bindings are available
# [http://galinha.ucpel.tche.br/platforms#openmoko Chicken Scheme interpreter] and runtime library packaged for OpenMoko
+
# [http://galinha.ucpel.tche.br/platforms#openmoko Chicken Scheme interpreter] and runtime library packaged for Openmoko
 +
# [[ECL]] (on Debian)
  
 
=== Java ===
 
=== Java ===
  
# 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.)
+
# 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.)
# A full J2ME implementation takes about 2 Megabytes of space.  [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (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 no-JIT [http://jamvm.sourceforge.net/ JamVM] as an alternative.
+
# A full J2ME implementation takes about 2 Megabytes of space.  [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (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 [http://jamvm.sourceforge.net/ JamVM] as an alternative.
 
# Java is very C-like.
 
# Java is very C-like.
 
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?  
 
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?  
Line 233: Line 248:
 
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.   
 
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.   
 
# 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.
 
# 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.
# 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.
+
# 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, groovy, python, and javafx.  This would be a huge win for the device.
 
# JavaFX is a Multimedia based scripting language that adds wow to devices
 
# JavaFX is a Multimedia based scripting language that adds wow to devices
 
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
 
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
Line 248: Line 263:
 
# Not a scripting language, but offers garbage collection and other nice features.
 
# Not a scripting language, but offers garbage collection and other nice features.
 
# Already used in a similar setup on Nokia 770/800.
 
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
+
# Nicely cross-platform; same binary could be run on Openmoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
 
# 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. (not all classes are needed))
 
# 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. (not all classes are needed))
# With IKVM, it can run java apps.
+
# With IKVM, it can run many java apps.
 
# IronPython and IronRuby would be great boons.
 
# IronPython and IronRuby would be great boons.
  
Line 275: Line 290:
  
 
By looking at the [http://www.gnome.org/mobile/ 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? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)
 
By looking at the [http://www.gnome.org/mobile/ 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? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)
 +
 +
I agree with the above: Python is a well developed and maintained language, easy to learn, and plays well with others (C/C++). As stated above, it is popular and part of the GMP. --[[User:King|King]] 04:19, 2 October 2008 (UTC)
 +
 +
[[Category:Software ideas]]

Latest revision as of 18:49, 23 November 2009

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.

People have already started to write for the Neo at least in shell script and Python.

Contents

[edit] 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 ? Medium Heavy JIT/gcj Y (Jython/JRuby/Groovy)
Python Mature/Active Light Medium Pyrex/RPython Y
C#/mono/IronPython In development Heavy Heavy JIT Y (IronPython)
Perl Mature Light Medium ? Y
Haskell ? Heavy Light Native, JIT and bytecode Y
LUA Mature/Active Light Light N Y
Ruby ? Light Medium N Y
Scheme Mature/Active Light Light Y Y
Squirrel Mature/Active Light Light N Y
PHP-GTK Active Light Medium Bytecode Y

[edit] 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.

[edit] 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?

[edit] The Languages (already included)

[edit] 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#Command_line is usable from the command line. GTK2 may be used via gtk-server.

[edit] AWK

  1. already included, very powerful - example

[edit] SED

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

[edit] 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.


[edit] The Languages (not included)

Warning: opinions ahead

[edit] 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 is 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.

[edit] 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#Python. GTK bindings are part of the Gnome project.
  6. Manually using Bluetooth has parts in Python
  7. Performance is good. Psyco can make it extremely good, but that is unlikely to be available to Openmoko. The PyPy JIT is on it's way.
  8. By using Pyrex/PyInline/SWIG, hungry algorithms can get C-like performance. Nice benchmarks here. RPython (PyPy) already is somewhat usable and Shed Skin looks promising.
  9. Python can be embedded, although not trivially. DePython (footprint <200k) is proof of concept, but currently unmaintained. Tinypy may become usable.
  10. 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
  11. OLPC uses Python heavily and may produce applications suitable for porting to Openmoko
  12. Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
  13. Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as this media player.
  14. Jython would make it almost 'free', but it's slower and not identical to CPython.

[edit] 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.

[edit] 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.

[edit] 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
  6. Chicken Scheme interpreter and runtime library packaged for Openmoko
  7. ECL (on Debian)

[edit] 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, groovy, 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. However, this means no multiple languages on one JVM and nullifies it's value in this list.

[edit] 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.

[edit] 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. (not all classes are needed))
  5. With IKVM, it can run many java apps.
  6. IronPython and IronRuby would be great boons.

[edit] Squirrel

  1. A scriptable language with the interval VM architecture modeled after Lua but with a C like syntax.
  2. gtk+ binding available
  3. A little more resource hungry than Lua, but otherwise using less resources than Python or Perl or Java
  4. Used in actual shipping games but also in other apps on Windows and GNU/Linux

[edit] 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)

I agree with the above: Python is a well developed and maintained language, easy to learn, and plays well with others (C/C++). As stated above, it is popular and part of the GMP. --King 04:19, 2 October 2008 (UTC)

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.

People have already started to write for the Neo at least in shell script and Python.

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 ? ? ? Pyrex / PyPy JIT Y
C#/mono ? ? ? JIT N
Perl ? ? ? ? ?
Haskell ? ? ? Y Y
LUA Mature/Active Light Light JIT(Lua-JIT) Y
Ruby ? ? ? ? ?
Scheme Mature/Active Light Light Y Y

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#Command_line 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#Python. GTK bindings are part of the Gnome project.
  6. Manually using Bluetooth has parts in Python
  7. Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko. The PyPy JIT is on it's way.
  8. By using Pyrex/PyInline/Boost/SWIG, taxing algorithms can get C-like performance. Nice benchmarks here. PyPy already is somewhat usable and Shed Skin looks promising.
  9. Python can be embedded, although not trivially. DePython (footprint <200k) is proof of concept, but currently unmaintained.
  10. 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
  11. OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
  12. Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
  13. Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as this.
  14. 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
  6. Chicken Scheme interpreter and runtime library packaged for OpenMoko

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 no-JIT 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. 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. (not all classes are needed))
  5. With IKVM, it can run java apps.
  6. IronPython and IronRuby would be great boons.

Squirrel

  1. A scriptable language with the interval VM architecture modeled after Lua but with a C like syntax.
  2. gtk+ binding available
  3. A little more resource hungry than Lua, but otherwise using less resources than Python or Perl or Java
  4. Used in actual shipping games but also in other apps on Windows and GNU/Linux

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)