Here’s a common scenario, you’re on-site demonstrating some fancy new Javascript interface you’ve written, only to discover that some part of it that was working so beautifully on your dev box inexplicably breaks. hmm you think, must be a bloody IE bug. You try it in Firefox.. it still doesn’t work, what the?!

Later that day you get home and on a hunch run a quick search through your source tree:

> ack  ‘console.log’
www/extras/wobject/Survey/dd.js
96:console.log(destEl);

The culprit is Firebug’s console.log() function. The damn thing is just too handy. So handy that a few years ago the collective web development community abandoned alert() as the #1 debugging weapon of choice. Now we all use console.log(). Forget the firebug debugger, nobody can be bothered bringing up their js source in the script tab and clicking the break button or setting a watch variable, that’s like, 4 clicks too many man! Whack in a of console.log(a, b, c)s and it’s all there, plain as day in the firebug console, ready to be clicked on and examined further  in the DOM tab.

Until you forget that not everyone in the world runs firebug. Hard to believe, I know. But actually, the problem occurs for anyone who hasn’t got the firebug console turned on for YOUR SITE. The problem being of course that you probably always have the firebug console turned on for your site, but no-one else in the world does. So the likelihood of being bitten are pretty high.

Of course, there are lots of workarounds. One approach is to just define console.log as an empty function (and while you’re at it, you may as well define all the other Firebug functions too):

if (!("console" in window) || !("firebug" in console)) {
 var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
 window.console = {};
 for (var i = 0, len = names.length; i < len; ++i) {
 window.console[names[i]] = function(){};
 }
}

In my case the code was part of a drag and drop method used in WebGUI. And like all sane web projects, WebGUI oursources its cross-browser Javascript concerns to a library (in our case YUI). And it turns out YUI has a perfectly good logger of its own, guaranteed to be available on any page that YUI is loaded onto. Hello YAHOO.log();

Now, “YAHOO.log” is 1 letter shorter than “console.log”, so why does everyone end up using console.log() all the same? Maybe they don’t like typing in upper-case. More probably they noticed that when they use YAHOO.log(‘blah’); nothing appears in the firebug console. What gives? Well, you need to tell YAHOO to pass on log  messages to the console, that’s what. Type the following line first, and everything will work out just fine:

YAHOO.widget.Logger.enableBrowserConsole();

Of course, that’s a lot more letters than just typing console.log(), and what’s more you need to use YAHOO.lang.dump() to serialise objects passed to log() (no nice firebug object examination), which admittedly is a lot less fun. But it does mean a little less broken code in production.

I’ve been getting a lot out of The Little Schemer recently. It’s an amazingly little book. One topic covered is the Halting Problem which I first came across back when I was studying Theory of Computation at university. The authors use Scheme throughout the book, but I thought it’d be useful to translate the discussion into Javascript since Javascript is quite accessible for newcomers to functional programming.

Some functions always return a value. For example, the following simple function always returns the value of PI:

function pi(){
    return Math.PI;
}

Some functions go into infinite loops and never halt. For example, the following function enters a while loop and never comes out:

function eternity(){
    while(true) {
        // goodbye, cruel world
    }
}

Wouldn’t it be nice to be able to tell ahead of time whether a function is going to halt or go into an infinite loop? (cue evil laughter from the computer scientists in the back row)

Let’s write a function that tells us whether another function halts. (It’s easy to write functions that take other functions as arguments in Javascript because it’s a functional programming language). What would such a function look like?

function halts(fn){ // takes one argument, fn (a function)
    // code that determines if fn halts goes here
}

We’re not sure yet what code to put into the function body, but let’s start by looking at what we know about this function. It has to return True or False. True if the argument fn halts and returns a value, False if not. Simple right?

Let’s try out halts() on some functions we’ve already talked about to get a feel for how it’s supposed to work.

halts(pi); // returns true because pi() halts
halts(eternity); // returns false because eternity() doesn't halt

So far so good. Ok, let’s create one last function just for fun and see how halts() goes.

function maybe() {
    if (halts(maybe)) {
        eternity(); // never ends..
    } else {
        return "ok I halted!";
    }
}

The question is, does maybe() halt? Well let’s see..

• Let’s assume that maybe() halts. Therefore the if clause is true and so eternity() gets called.. meaning that maybe() never halts. Wait! That can’t be right! We just contradicted ourselves. We must have guessed wrong.
• Ok, in that case, let’s say that maybe() doesn’t halt. Therefore the else clause gets called instead, and we return a value. Meaning that we halted. But that’s a contradiction too!

What this means is that it’s impossible to write a function like halts() that determines whether another arbitrary function halts or not, because the very definition of such a function leads to a contradiction. Sucks to be a programmer huh?

Thanks Alan M. Turing (1912-1954), and Kurt Gödel (1906-1978).