Languages for talking to phones


There are a number of runtime environments available or in the works for open phone platforms (e.g. Python, Perl, Ruby, Java). Instead of using one of these, we decided to port a runtime for a language you may not have heard of, called OCaml.

If you’re interested in writing code faster and with fewer bugs, you should give OCaml a look. Its advanced type system prevents whole classes of bugs in the same way that garbage collection does. We like it so much that we use it whenever we can.

At first we thought that “whenever we can” meant only on the server; we thought the time it would take to port OCaml to phone operating systems would be prohibitive. However, after a little investigation, we decided to port the bytecode runtime to the Nokia S60 platform. It is turning out to be easy. The runtime is a beautiful piece of code and very portable.

Doing our own port gives us the same degree of control as writing native code, while retaining the productivity advantages of a runtime environment. It also helps maintain portability across different platforms.

We expect OCaml to make a big difference in our ability to get working software out the door. Programming everything in C++ seems insane by comparison.

Use a runtime environment in mobile development


Mark Lam wrote a great post Monday about reasons to choose Java for embedded systems development. He starts with an anecdote about wanting to abstract away the complex security issues involved with native programming by creating a scripting language.

However, in order for the content to be interesting, the scripting language needed to provide more and more functionality like that of a full programming language. After numerous enhancements to the script engine, eventually I realized that I am re-inventing a solution just like the Java programming language.

This path has been — and likely will continue to be — followed by many companies building mobile products in order to isolate security risks and provide custom adapters for platform differences across a broad range of handsets. But it’s a lot of work to build a runtime environment from scratch, so Mark is hoping to persuade his readers to choose Java before investing in that work. Because he is addressing an audience of embedded system developers, some of Mark’s points and his ultimate conclusion do not necessarily apply to mobile ISVs. However, his underlying argument is sound: using a runtime environment provides many advantages, and rolling your own will come up lacking.

Just in case you’re not convinced that you should seriously consider using a runtime environment for mobile development, the Symbian Developer Network is publishing a series about it. The first two present a business case (pdf) and describe the concept (pdf).

Today, if the handset runs an OS with a closed development environment, then the only managed environments available are JavaME and in some cases, Flash Lite. But a lot of interesting possibilities exist for handsets that have an open development environment, such as Symbian (S60/UIQ), Windows Mobile, Linux. Coming up, we’ll talk about some of the possibilities we considered and what we wound up using.

« Previous Page