Programs must be written for people to read, and only incidentally for machines to execute.

Abelson & Sussman, SICP

There’s a programming paradigm which I shall call, for the lack of a better name, bail out early. It’s so trivial that it almost doesn’t deserve a name, not to mention a blog post. Yet I often come across code that would be so much clearer if bail out early was used. Consider some code like this:

function transmogrify(input) {
    if (input.someConditionIsMet()) {
        var result;
        result = processInput(input);
        if (result) {
            return result;
        } else {
            throw UNDEFINED_RESULT;
        }
    } else {
        throw INVALID_INPUT;
    }
}

There’s a lot of if/else going on here. In the bail out early paradigm, you would try to write this without any else clauses. The trick is to sort out the problematic case first:

function transmogrify(input) {
    if (!input.someConditionIsMet()) {
        throw INVALID_INPUT;
    }

    var result;
    result = processInput(input);
    if (!result) {
        throw UNDEFINED_RESULT;
    }
    return result;
}

See how much flatter the structure of that program is? There are some other advantages:

  • Because you no longer put the main flow inside if statements, your programm is often easier to refactor. If for instance the sanity checks occur in multiple places of your program, you can simply factor them out into a utility function without messing up the structure of your code.
  • You generally have to indent less. And when you move code around, you have to reindent less — particularly pleasant when you’re coding in Python where indentation is significant.
  • In languages with curly braces like my fake JavaScript above, you don’t have to worry about blocks spanning many many lines, thus putting the opening and closing brackets so far a part that you no longer can tell what the closing bracket is actually closing.

JavaScript has picked up lots of pythonisms over the last few years which is obvioulsy a Good Thing(tm). Aza Raskin of Mozilla has now created Pyscript, a version of JavaScript sans curly braces. As a fellow Pythonista I too find curly braces aesthetically unpleasant. But I don’t think it’s the pressing issue. At the end of his post, Aza asks “What other ways can we make Javascript syntax prettier and more readable?” Let me tell you by pointing to the elephant in the room.

Writing a class/object in JavaScript, especially “subclassing,” weirds me out.

I just can’t make my peace with the functions-implicitly-become-object-constructors idea. I can see how it might make sense in a prototype world. But once you use functions to define objects, you must use the new operator for instantiation. This means there are some functions you call right away and some you don’t. I just don’t understand why it would be so bad to have a new language construct for defining objects?

The lack of such a one-and-only language construct leads to a plethora of ways how to define object methods. Some like doing it this way:

function MyObject() {
  /* constructor here */
  this.aMethod = function() {
    /* method here */
  }
}

while others like to monkey-patch them in, like so:

function MyObject() {
  /* constructor here */
}
MyObject.prototype.aMethod = function() {
  /* method here */
}

or even:

MyObject.prototype = {
  aMethod: function() {
    /* method here */
  }
}

I’m sorry, that’s just too many ways for doing something all too common in object-oriented languages: defining objects. Not to mention the prototype-less one:

var MyObject = {
  aMethod: function() {
    /* method here */
  }
}

(Of course, when using Mozilla’s JavaScript engine you can also monkey patch a prototype into this via MyObject.__proto__ = {...}. In fact, the Mozilla folks like using __proto__ all the time to specify the object’s baseclass, uh, I mean baseprototype.)

I know what you’re going to say now. People could just settle for one way and impose that as a coding convention. But why hasn’t that happened? My suspicion is that because none of the choices are truly great. The language itself doesn’t encourage a particular choice more than any other, and that’s bad. Arbitration like that is just one step away from Perl.

Coming back to Aza’s Pyscript, I think it’s a useful exercise because it shows how much you can improve JavaScript with just a few lines of, uh, JavaScript. Perhaps I should give it a whirl and come up with a language construct for creating prototype-based objects, including a decent inheritance syntax. What do you think that should look like?

Update: I’ve written a follow-up post that contains a solution.

Attention, attention! This is a service announcement!

I haven’t been blogging much about Python and Zope lately. In fact, as some of you may have noticed, I’m no longer involved in Zope at all. I continue to use Python, though. To keep your feed aggregators a.k.a. planets topical I suggest removing my blog feed from Zope related planets and switch Python related aggregators to my Python category feed.

If any of you readers have found my blog through one of the Python and Zope planets and still enjoyed my other posts, I suggest adding my general feed to your news reader so you continue to get updates. Thank you.

End of service announcement.

I’m what Alex Limi calls a tab power user. I always have a lots of open tabs in my Firefox. Right now it’s 38. Some of them are regular web apps that I never close (Gmail, Twitter, Facebook, etc.), some of them are websites that I’m currently using (project wikis, API references, etc.), and some of them are things I’ve opened for later reading (you might call them short-term bookmarks).

Clearly the standard tab bar in Firefox is completely impractical for this. There is, however, the Tree Style Tab extension which allows you to arrange tabs in a vertical tree at the left or right hand side of your browser window. Apart from the obvious advantages of being able to sort tabs in a tree, it also solves two simple visual problems: On modern widescreen displays you want to waste as little vertical space as possible. Moving the tab bar from a horizontal toolbar to a vertical sidebar therefore not only gives you more vertical space for the content window but also more space for the tabs. The latter is very important obviously when you have lots of open tabs.

There’s just one thing that’s always bothered me a bit about Tree Style Tab: The default theme on OS X may look nice but it wastes a lot of space by trying to make tabs look like, uh, tabs. It also doesn’t actually feel like a native OS X UI. Just consider iTunes, Apple Mail or other applications with a sidebar tree…

Enter SidebarStyleTab. This little extension I cobbled together earlier this week restyles your vertical tree style tab bar to look like a sidebar you know from other OS X applications (including the sidebar in Firefox itself). It’s not 100% perfect yet, but for me it’s a big improvement over the default OS X tree style tab theme. I might get around to fixing the few remaining UI quirks eventually, but I welcome others to beat me to it: the code is on GitHub.

SidebarStyleTab in action

SidebarStyleTab in action

P.S.: I think this is not the end of redesigning tabs in Firefox. This is obviously a much debated topic to which I might eventually add my 2 cents. But not today :)

Over the Christmas holidays I’ve been thinking about the web 2.0, social web, the cloud, or whatever you might call it, and what’s bothering me about it right now. Not being in control of your data is one issue, but I’m not going to talk about it here. Mostly because it’s orthogonal to my other big beef I have with “the cloud”: usability. Let me explain.

Right now webapps are many mostly disconnected apps that are just loosely connected by a browser. Now I know you can have some inter-app connectivity nowadays, mostly thanks to feeds (e.g. Twitter & Facebook). But it’s not really what you get on the desktop, is it. There’s no drag’n’drop from Flickr to Gmail like there is from iPhoto to Thunderbird, for instance. I’m not suggesting that we implement drag’n’drop for the web, but I do wish there was a way to connect apps better, in a way that makes sense for the cloud. Right now we’re copy-and-pasting URLs or downloading stuff first just to upload it again. That feels a bit 1990s to me.

There’s another thing about cloud apps, and this one actually feels very 1980s to me, back when DOS was ruling the PC world: they all have their own UI. Indeed WordPress and Google Docs are about as similar to work with as Lotus 1-2-3 and the Norton Commander. You might now be thinking that surely there must be room for branding and that different apps demand different interfaces. Yet on the desktop there is surprisingly strong demand for coherence. Rightly so I say. Consistency matters. It boosts productivity because all people naturally form habits. Good UIs exploit this human trait.

For copyright see http://en.wikipedia.org/wiki/File:Lotus-123-3.0-dos.png

Lotus 1-2-3 for DOS. How far have we come?

For copyright info see http://en.wikipedia.org/wiki/File:IPhonehomescreen.PNG

Controlled platforms can be used encourage coherent UIs

I realise it’s going to be a long way before the makers of web apps can agree on common UI paradigms, if at all. It’s much more likely going to happen if you bring the cloud to a specific platform. The iPhone is a nice example: the Facebook and WordPress apps follow the platform’s UI paradigms just as much as the Email client the OS ships with. Of course, that platform on the desktop is the web browser. So while I think web apps themselves can still improve a lot in terms of usability, both the goal of integrating different web apps as well as pure practicality suggest that the browser is a good place to start improving the “cloud experience.”

This can and probably should start with small things, like authentication and identity management. As a technical basis, OpenID is great, yet it’s not available everywhere and when it’s available, it’s not as user friendly as it could be. Why should I have to sign in anyway? iPhoto works straight away, too.

Others have realised this as well. There’s Flock, the “social web browser.” It makes a nice effort of somewhat integrating web apps like Gmail, Twitter, Facebook, and Flickr. But its closed-source nature has prevented it from being adopted by the billions and getting much community support in the form of extensions, like Firefox upon which it is built. Mozilla themselves, however, are doing very cool stuff that might bring Firefox up to speed:

  • Ubiquity makes much copy-and-pasting unnecessary and for services like searching, translating, URL shortening, etc. you don’t even need to open a new tab and go to the respective web page anymore, Ubiquity lets you do it on-the-fly. This is the right thinking, but it needs to be built into the browser much, much more. Even more than what Taskfox, where the URL bar was replaced with a ubiquity-like command bar.
  • Weave is many things, but what I like most about it is the identity management part that integrates OpenID with the browser and provides a quasi single-sign-on for all other sites. This is exactly the kind of seamless cloud app interaction we need!
  • JetPack isn’t so much end-user technology as a developer platform for building Firefox extensions as easily as Greasemonkey scripts. That means it’ll be much easier to integrate web apps with the desktop app that is the browser, including for instance building more coherent UIs around existing web apps.

For copyright info see http://en.wikipedia.org/wiki/File:Ubiquity-screenshot.PNG

Ubiquity, the natural language equivalent of a context menu for Firefox

For copyright info see http://en.wikipedia.org/wiki/File:Flock_Screenshot.jpg

Flock makes an attempt at integrating the "social web"

All this sounds very exciting. In fact, I think an awesome platform for the cloudy web would be a cocktail of Flock, Taskfox, Ubiquity, Weave and JetPack. Unfortunately that all sounds a bit far fetched for Firefox 4 and that’s not even due till next year. Plus, things like the Home tab challenge give you an idea of what they’re actually planning for Firefox 4. A “Home tab”? Seriously? And then there’s Raindrop which aims at integrating various communication channels, e.g. email, twitter, etc. The prototype is impressive. Sadly however this takes the whole integration effort on a tangent that I don’t consider fruitful. First of all it’s restricted to messaging, and secondly it’s designed much more like a web app than what the browser really is supposed to do: provide desktop integration.

So the question that intrigues me is why not take what awesome components Mozilla have produced and turn them into a cloud browser. Why not go mix that cocktail?

On a last note, I think it would be interesting to see how Google is tackling this problem at all. After they have built a brand new browser from scratch, but apart from impressive speed and stability it’s still a very conventional browser. It’s hard to tell what they’re cooking up next, but so far neither Chrome OS nor Google “yet-another-cloud-app” Wave have blown my socks off.

Follow

Get every new post delivered to your Inbox.