On Language/Platform Restrictions…

Editorial Note: I know I said I was going to have a Kiwi Pycon Roundup, but I’ve been really busy recently. I’m now going to wait until the conference video/audio is posted then I can give a proper roundup and post people to the talks I found particularly interesting.

OK, today I’m having a rant. This isn’t going to be an ill conceived rant about a company, like my last one. This one is about something of a general feeling that I’ve been getting recently. I want to talk about what I call Language/Platform restriction (I’m open to a better name). This can best be described by taking an example, the best of which is Android.

So, you want to develop an Android application, but you’ve got no experience in this area. So what do you do? You head over to the Android Developer site and read some of the tutorials and documentation. To your dismay you find all the code is in Java, but you’re a Python programmer. There doesn’t seem to be any way to use your favourite language on Android, despite everyone claiming that Android is an open platform.

Granted, this example is a little contrived. The chances of any developer not knowing that Android is a Java only platform are pretty small. This isn’t even my own experience as I’m pretty good with both Java and Python (though Python is my favourite). I guess my point is that developers have preferences over which language they like to use and that these preferences seem to be being largely ignored.

Now, Android does have a working Python implementation as part of the SL4A project, but this is very much a scripting environment not an application development environment. There is no native access to the Android APIs that are required to develop a fully fledged application. Also, in my opinion its usefulness as a scripting environment is limited by the lack of a Free Software cron equivalent, to run scripts automatically.

Lest you think I’m picking on Android, this problem isn’t specific to that platform. It’s also present on The Web. “Oh No!”, I hear you cry, “The Web is an incredibly open platform, you can use any language you want!”. In some ways this is true, on the server side, yes you can pretty much use any language you want (I’ve never seen any web apps written in assembly, but I’m sure it’s possible). The client side is another matter though.

If we restrict ourselves the technologies which make up “The Open Web” (basically ignoring Flash and Silverlight), we really only have one option: Javascript. Now, Javascript has historically been a complete mess. Granted it’s getting a lot better with HTML5, but it still kinda sucks. It doesn’t have any proper OO (please don’t offer up that “a function is an object” crap, as a sorry excuse). It’s still pretty low level, certainly compared to Python and it seems to be “the language which syntax forgot”.

This worries me. It actually worries me more than the Android situation. The reason for this is that I think The Web is going to be the main application delivery platform going forward and that Free Software needs to seize on this to create a suite of Free cloud applications, just as we have for the desktop. However, the lack of a choice of languages puts me (for one) off.

There have been efforts to port Python to the browser, specifically Pyjamas and Skulpt. There are problems with both these implementations. Pyjamas is too tied to its own application framework (which come from Google Web Toolkit) and it basically ends up bringing desktop like application programming to The Web. Maybe this isn’t a bad thing, but it seems to miss the full potential of The Web. Really what we need is something that takes advantage of all The Web’s APIs, but without having to use Javscript. Skulpt, although initially promising, does the compilation from Python to Javascript on the client side, thus multiplying the overhead in doing so by the number of clients (granted its distributed, but it still seems wasteful when this only needs doing once).

I should also take a minute to mention Google’s Native Client plugin. Although its not really part of the standard Open Web technology suite, it is trying to expand beyond what Flash and Silverlight offer. Basically it’s a way to run native x86 code inside a web application and expose methods through a Javascript API. You can potentially run anything in there. There are some continuing efforts to port Python to this platform, but I think this is the wrong way to go too. It’s not really intended to be a full runtime, its more like a sandboxed version of ctypes for Javascript.

In both these situations (Android and The Web) the best option is for native support for other languages to be added directly to the underlying virtual machine. However, this doesn’t look like it’s going to happen any time soon, so we might need some other solutions. Pyjamas and Skulpt have demonstrated that it’s certainly possible to compile Python to Javascript so I think that’s a low hanging target. I haven’t seen anything more promising than SL4A for Android yet, and porting dynamic languages to run on Dalvik strikes me as much harder (given the static nature of Java).

Throughout this post I’ve kind of focussed on getting Python to run on other platforms, but what I’ve said pretty much goes for Perl, PHP or any other language. If anyone has any thoughts on this topic, or details of other projects I should check out, please get in touch. My main fear is that we’re going to end up with a situation where there is not choice of programming languages for any given platform and that some of the best languages will be left out in the cold.

4 thoughts on “On Language/Platform Restrictions…

  1. BlackJack says:

    JavaScript is a prototype based OO language and there are at least three common ways to do OO with it. Claiming it has no OO is wrong and prototypal OO isn’t a „sorry excuse“ but just different than “classy” OO. So the problem may be more that there’s *too many* ways to write OO programs. If you like Python’s OO model there is `classy` (http://classy.pocoo.org/) to bring Python inspired classes into JavaScript.

    Another nice language for the browser which compiles to JavaScript is CoffeeScript (http://jashkenas.github.com/coffee-script/). It reminds me of the experience when I discovered Python and compared my Python code with my Java code. More concise syntax with significant whitespace and it takes much of the boiler plate code out of JavaScript. There is also a “class“ keyword to support “classy” OO.

  2. Hi BlackJack,

    Thanks for your comment. I do acknowledge that Javascript has a form of OO, my actual words were that I don’t think it has a ‘proper’ form of OO. That is just my opinion, but I have good reasons for not believing that the prototype model is as good as the ‘classy’ model (not least because it’s confusing – how many questions or howtos have you seen on doing OO in Javascript?).

    Thanks for the links, I’ll be sure to check them out. My point wasn’t really that Javascript is missing features, more that there should be a choice of language on any given platform.

    Thanks again,


  3. BlackJack says:

    I don’t think prototype based inheritance itself is confusing but JavaScript’s implementation of it is. Before JavaScript 1.8.5/ECMAScript 5 you need additional code if you want easy to use prototypical inheritance like in Io (http://iolanguage.org/) and you also need additional code to get classy OO inheritance. The only thing that comes “for free” is the functional inheritance model.

    Some of the confusion can also be attributed to people who are used to classy inheritance and see the similarity to Java syntax and the “new“ keyword and then somehow refuse to adapt their views from a class based, procedural language to a prototype based, much more functional language. So their expections simply collide with reality. But that doesn’t make prototypical inheritance inferior. Or superior. IMHO.

    In a way it is superior: Classy inheritance can be easily implemented with JavaScript, like classy.js and numerous other implementations prove. But it is hard to impossible to teach classy languages like Java prototypical inheritance.

  4. I suppose in the end it comes down to personal preference and what you are familiar with. I’ve always used classy OO and so have never seen the need for an alternative. Also, it seems that most popular languages use classy OO (Java, C++, Python, C#…) so JS goes against what a lot of programmers know.

    I definitely agree that JSs implementation of prototype based inheritance is confusing, but the link you provided appears to be down so I can’t comment on the Io language.

Leave a Reply

Your email address will not be published. Required fields are marked *