Monday April 12, 2010
With the current flavor of the week being a certain new section in Apple’s iPhone SDK license, there’s no shortage of sane and not-quite-as-sane commentary being thrown around. This post isn’t really about that, but it has triggered some people to argue that they should be able to write their applications in Ruby or any other interpreted language. Which shows that they either have no clue about mobile platforms, or think their users’ device is something they can just abuse at will.
I love Ruby, but it has little place running an entire application on a mobile device, as awesome as that would be. On a device (fruit logo engraved or not) with limited processing power, memory and battery time, do you really want to run an entire application that wastes spends many CPU hours just interpreting things? I’m pretty sure your potential users would have an issue with your application draining the battery much faster than your competitors application, or using substantially more memory.
“CPU time is cheap, programmer time is not” has become the mantra of the dynamic language world, with good reason. But it falls short when you’re no longer running on a machine with 16 or more CPU cores and eight gigabytes of RAM. In fact, if you spend some time reading through the iPhone SDK APIs you’ll find numerous encouragements to be mindful of battery use (I imagine the same being true for Android and other mobile platforms as well). CPU time and memory is the currency your application has to trade, if you waste it your users will not be too impressed with either your application or the platform as a whole (for good or for worse they reflect upon each other), both being a very bad thing for you.
Moore’s law of course applies to mobile CPUs as well, the difference between this years hardware and the previous one is significant regardless of manufacturer, but it’s more of a steady improvement than a giant leap forward, so you don’t quite have the luxury to trade in all your programmer time for CPU time just yet since there’s only so much to go around.
There’s also some interesting economics in this from the perspective of the mobile device manufacturers. Faster CPUs are more expensive, so if you can provide adequate performance at a reasonable price (cheaper CPUs means cheaper hardware for consumers, thus a competitive advantage) by only using a compiled language in your SDK (along with an API to save even more resources for things such as multitasking), then we’re suddenly talking about a significant difference in dollars and cents.
If your entire SDK is fairly resource intensive, such as Palm’s WebOS (both rendering HTML and interpreting javascript is a significant investment for a mobile CPU), then your device suddenly becomes much more expensive and it’ll still run out of battery in less than a day. The internet reviewers and know-it-alls does not approve of such shenanigans.