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.
As an avid OCaml hacker I wonder whether you have any plans to make your runtime port available as open source software (OCaml being GPL and all)?
Thanks for asking. The port is still under development, but we will definitely be releasing the source before shipping it on phones.
Man, this is so awesome!
I wish we did something like that @Vindigo.
Writing all those apps would’ve been so much easier…
In my experience, it is true that OCaml boosts productivity thanks to its type system.
However I still have mixed feelings about it when it comes to readability and the stability of the language itself (just consider the recent CamlP4 incompatible changes).
C and C++ bindings are added to OCaml by the day. While many hail this as healthy for the language, I view it as a failure: it destroys code portability because now you depend on the underlying platform, it is no testament to OCaml’s versatility and it voids its safety.
By analogy, would you rather use a JNI JDBC implementation and get into all kinds of threading problems, memory corruption and the like rather than use a pure Java JDBC driver?
Not to curb your enthusiasm though! OCaml fills a nice niche between the lax C and C++ legacy and the strictness of Ada (btw Ada is eminently more readable).
It runtime is currently non-preemptive; not a problem in your case since you can develop a runtime that plays well with active objects.
I applaud this strategy that I am sure will help boost portability in the messy, unreliable, under-documented world of mobile software development (about which I could rant on and on but that’s another issue)
I will be reading this blog in the future and hope you will report about this experience!
So, I’ve been ruminating about this for a few days now. It’s a fascinating choice.
I get that by “owning” the runtime, you essentially gain machine level control of the device while still getting to program in a more abstract language. It’s a conceptually similar choice to that of building your own phone-side browser rather than relying on the built-in browser.
That said, why not port a Java runtime of your choosing? At least then, you’d still have a shot at deploying on “closed” environments that might only give you access at the J2ME level. Perhaps you’ve decided that these smaller and/or more “closed” devices aren’t in your immediate roadmap.
I’ve seen some ugly caml code in the telecom world in the last year. I almost feel that languages are readability agnostic (perl and ada excluded). Vindigo had some amazingly readable server code – not because Java necessariy lent itself to that – but becuase the team placed a high value on reading code.
Unfortunately, it will be hard to draw conclusions from the effectiveness of your initial work, if only becuase you guys are good enough to make any framework run well. It reminds me of a recent track day – driving my fancy new Porsche – when I had my posterior handed to me (passed like I was sitting still) by a seasoned instructor driving a Mini. The point being that the skill of the driver (or in this case the programmer) plays such a huge part in the overall delivery, that it’s hard to independently judge the effectiveness of the tool. If you’re planning on bringing in lots of newer/younger programmers, that will be more interesting.
Matthew