Python/Ruby as mobile OS

Question

I was wondering why smartphone/mobile device OSs are not written to allow dynamic languages as the language of choice? iPhone uses Objective-C, Google Android uses Java, Windows Mobile uses any manner of .NET language.

What would be the reasoning behind a mobile OS being written in Python, Ruby, or any other dynamic language? I understand that at a low level they would not cut it but C or C++ would be fine for that and Python, for example, could be the layer on top to interact with it. I mean, there is Jython or CPython.

I was just wondering why we do not see more dynamic language support in today's mobile OS's.

Heilman

Answer 1

In general it's all of these things. Memory, speed, and probably most importantly programmer familiarity. Apple has a huge investment in Objective C, Java is known by basically everyone, and C# is very popular as well. If you're trying for mass programmer appeal it makes sense to start with something popular, even if it's sort of boring.

There aren't really any technical requirements stopping it. We could write a whole Ruby stack and let the programmer re-implement the slow bits in C and it wouldn't be that big of a deal. It would be an investment for whatever company is making the mobile OS, and at the end of the day I'm not sure they gain as much from this.

Finally, it's the very beginning of mobile devices. In 5 years I wouldn't be at all surprised to see a much wider mobile stack.

Myelitis

Answer 2

Contrary to the premise of the question: One of the first mainstream mobile devices was the Newton, which was designed to use a specialized dynamic language called NewtonScript for application development. The Newton development environment and language made it especially easy for applications to work together and share information - almost the polar opposite of the current iPhone experience. Although many developers writing new Newton applications from scratch liked it a lot - NewtonScript "feels" a lot like Ruby - the Newton had some performance issues and porting of existing code was not easy, even after Apple later added the ability to incorporate C code into a NewtonScript program. Also, it was very hard to protect one's intellectual property on the Newton - other developers could in most cases look inside your code and even override bits of it at a whim - a security nightmare.

The Newton was a commercial failure.

Palm took a few of Apple's best ideas - and improved upon them - but tossed dynamic language support as part of an overall simplification that eventually led to PalmOS gaining a majority of the mobile market share (for many years) as independent mobile software developers flocked to the new platform.

There were many reasons why the Newton was a failure, but some probably blame NewtonScript. Apple is "thinking different" with the iPhone, and one of the early decisions they seem to have made is to leverage as much as possible off their existing core developer base and make it easy for people to develop in Objective C. If iPhone gets official support for dynamic languages, that will be a later addition after long and careful consideration about how best to do it while still providing a secure and high-performance platform.

And 5 minutes after they do, others will follow. :-)

Confidante

NewtonScript required a lot of resources (CPU and memory) for a handheld device at the time; the performance was perfectly acceptable, though. At the end, the MessagePad 2100 was nearly $1000, a >100MHz StrongARM with 4MB RAM whereas a Palm Pilot was much cheaper, ran in <1MB RAM with a slow 68K-derivative processor. Of the mainstream languages today, NewtonScript is most related to JavaScript - they're both prototype-based. The Danger/Android platforms are probably the closest to this ideal today, as both of their Java VMs perform a preprocessing step on the host and are relatively simple. – Aeromarine

Actually, NewtonScript was the second language for Apple’s Newton project: The first was even more dynamic, Dylan [probably a pun on Dynamic Language], implemented in Macintosh Common Lisp. That project was killed, replaced by something with less unacceptable performance. (I love the Newton as a programmer, but even I have to admit that for the user, it was too slow.) Time will tell whether Apple’s competitors are now repeating Apple’s mistake. – Boohoo

One of the features of NewtonScript, differential inheritance, allowed this very dynamic, object-oriented programming language (which could also be compiled into byte code) to function with very low memory requirements, considering. It meant that child/related objects need only needed to store data that was different than parent/related objects. Of course, the searching to implement this lead to some of the performance issues. io, a NewtonScript cousin, also implements differential inheritance. – Fern

Answer 3

The situation for multiple languages on mobile devices is better than the question implies. Java (in its J2ME incarnation) is available these days even in fairly cheap phones. Symbian S60 officially supports Python, and Javascript for widgets, and there's a Ruby port although it's still fairly experimental. Charles Nutter has experimented with getting JRuby running on Android. rhomobile claims to allow developing an app in Ruby which will then run on all the major smartphone OSes, although that kind of portability claim implies restrictions on what those apps can achieve.

It's important to distinguish between the mobile OS (which does operating system stuff like sharing and protecting resources) and the runtime platform (which provides a working environment and a set of APIs to user-written applications). An OS can support multiple runtimes, such as how you can run both C++ and Java apps in Windows, even though Windows itself is written in C++.

Runtimes will have different performance characteristics, and expose the capabilities of the OS and hardware to a greater or lesser degree. For example, J2ME is available on tons of devices, but on many devices the J2ME runtime doesn't provide access to the camera or the ability to make calls. The "native" runtime (i.e. the one where apps are written in the same language as the OS) is no different in this respect: what "native" apps can do depends on what the runtime allows.

Ulrikaumeko

Answer 4

I think that performance concerns may be part of, but not all of, the reason. Mobile devices do not have very powerful hardware to work with.

I am partly unsure about this, though.

Attenuant

Answer 5

Jailbroken iPhones can have python installed, and I actually use python very frequently on mine.

Momently

Answer 6

One of the most pressing matters is garbage collection. Garbage collection often times introduce unpredictable pauses in embedded machines which sometimes need real time performance.

This is why there is a Java Micro Edition which has a different garbage collector which reduces pauses in exchange for a slower program.

Refcounting garbage collectors (like the one in CPython) are also less prone to pauses but can explode when data with many nested pointers (like a linked list) get deleted.

Carbamidine

But the iPhone makes you manage your own "garbage" by using retain counts. You have to actually release your objects or you will cause your own leaks. – Heilman

@Tacoman, that's called reference counting. You are doing it manually, but its classified as the same thing. – Carbamidine

Answer 7

I suspect the basic reason is a combination of security and reliability. You don't want someone to be easily able to hack the phone, and you want to have some control over what's being installed.

Milling

irrelevant - you can remove the python standard libraries and create a subset that is secure and reliable. – Megadeath

Oh, don[t be silly. Remove the python standard libraries and you still could install uncontrolled, untested code. – Milling

so what? if you don't have any libraries to touch the kernel, how can you "hack the phone"? If you want every code to be tested and controlled, that's managed by digital signatures, like Apple did, so it's still not related to language itself. – Megadeath

by writing code against the interpreter. If yoiu can't do anything to affect the phone functions, the interpreter's no use; if you can, then you can load untrusted code that doesn't undesirable things. That's why iPhone for example uses cryptographic signing to ensure loaded code has a trusted source. – Milling

iPhone did both. it used digital signature to prevent running unauthorized application, and it also used a limited set of SDK which would not break system easily. Again this is not about language - for example iPhone is using compiled binaries, not interpreters. – Megadeath

Answer 8

Memory is also a significant factor. It's easy to eat memory in Python, unfortunately.

Scrape

Answer 9

There are many reasons. Among them:

• business reasons, such as software lock-in strategies,
• efficiency: dynamic languages are usually perceived to be slower (and in some cases really are slower, or at least provide a limit to the amount of optimsation you can do. On a mobile device, optimising code is necessary much more often than on a PC), and tend to use more memory, which is a significant issue on portable devices with limited memory and little cache,,
• keeping development simple: a platform that supports say Python and Ruby and Java out of the box:
  • means thrice the work to write documentation and provide support,
  • divides development effort into three; it takes longer for helpful material to appear on the web and there are less developers who use the same language as you on your platform,
  • requires more storage on the device to support all these languages,
• management need to be convinced. I've always felt that the merits of Java are easily explained to a non-technical audience. .Net and Obj-C also seem a very natural choice for a Microsoft and Apple platform, respectively.

Denitrify

Answer 10

webOS -- the new OS from Palm, which will debut on the Pre -- has you write apps against a webkit runtime in JavaScript. Time will tell how successful it is, but I suspect it will not be the first to go down this path. As mobile devices become more powerful, you'll see dynamic languages become more prevalent.

Petra

Answer 11

My Palm has a Lua implementation that allows you to do reasonable GUIs, a fairly useless old Python 1.5, a superb Forth (which allows you to produce compiled apps) and a Scheme that allows for copmlete GUI dev.

At the recent Apple WWDC 2009, the Symbian alliance hosted an event the first day in an adjacent building with the teaser of a free Nokia 5800 for everyone coming even just for the lunch with marketing pitch - a US$350 phone. The event was to pitch developing for the Ovi Store and they had developers there and a programming competition on the afternoon.

The three languages they were emphasizing for development for Symbian were Java, Flash (lite) and Python. Python is the only option that allows you to work on the device or a PC and includes samples with OpenGL ES and other phone features.

With a utility to bundle Python apps into standalones that can be hosted on the store, I'd say Python on S60 is right up there as a contender for serious dynamic language on the (still) dominant platform.

Shakespeare

Answer 12

There is a linux distribution for OpenMoko Freerunner called SHR. Most of its settings and framework code is written in python and... well, it isn't very fast. It is bearable, but it was planned from the beginning to rewrite it in Vala.

On the other side, my few smallish apps work fast enough (with the only drawback having big startup time) to consider python to develop user applications.

For the record: Freerunner has ARM-something 400MHz and 128MB of RAM. I guess that once mobile devices cross 1GHz, languages like Python will be fast enough for middle-level stuff too (the low-level being the kernel).

Sign

Answer 13

Rhomobile's open source Rhodes framework offers this today. The world's first Ruby implementations for all smartphones.

Lon