peter.michaux.ca

Introducing Maria: The Real MVC

2013-06-02T19:05:00Z

In December 2011, James Ladd and I were chatting about JavaScript, its dynamic nature, and program design. During the discussion, James asked detailed questions and I needed to illustrate a few points about MVC. I created a GitHub repository with code we could discuss.

Fast forward 1.5 years, though many more conversations, much more research, testing, and refining, and the Maria framework for building MVC application in JavaScript is 1.0.0!

Over the past several years, the JavaScript community has been inundated with MV* frameworks. In the wake of the one-page app explosion, many JavaScript developers searched for ways to structure their larger browser applications more manageably. You can see in the source code of the frameworks that the authors were struggling away on their own attempting to solve the same problems. I’m willing to bet they went through a similar process I did trying to find discussions tailored to JavaScript about this famous MVC that was supposed to solve all their problems and more.

Why no one else chose to write an true MVC framework, I cannot figure. There is no doubt that the early Smalltalk MVC architecture inspired today’s MV* frameworks for JavaScript. My take on it was straight forward. The MVC architecture has withstood a 30 year test. It has passed that brutal test. It is still used for application programming. It is very useful for browser programming. Why not take this time-tested architecture and make a JavaScript framework true to the MVC that is implemented in Squeak Smalltalk and written about in Design Patterns? My experience with Maria has shown it was a good choice.

How true is Maria to the real MVC? Somewhere along the way, I downloaded the Smalltalk Squeak implementation, found the model, view, and controller classes, and started porting lines of Smalltalk to JavaScript. In places, the two really are that close. And it wasn’t like pounding a square peg in a round hole. It was a natural fit. As my detailed understanding of the Smalltalk implementation improved, more of my “creative” lines of code in the growing Maria were deleted and in their place appeared more ported lines from Smalltalk. Every single time it was an improvement. The Squeak classes have been around a long time. They are some of the best lines of code in all the world’s aggregate of software. They are a solid foundation on top of which to build an important application.

So if you want to build your applications on a solid foundation, I recommend you check out the Maria framework.

Early Mixins, Late Mixins

2012-10-26T23:17:00Z

In JavaScript, the language supplies us with several code reuse patterns. Prototype chaining gives us the primary single inheritance mechanism. Mixins are also an important pattern when we want one object to “inherit” functionality from multiple objects. There are several ways to implement the mixin process. This article looks at two contrasting implementations: early mixins and late mixins.

Late Binding

Let’s start with a quick review of what late binding gives us.

var adam = {
    greet: function() {
        return "hello";
    }
};

adam.greet(); // "hello"

When we ask adam to greet, the method to be executed is looked up at the time of the call. This is late binding and means if we redefine the greet method, subsequent calls will use the new definition.

adam.greet = function(name) {
    return "hello" + (name ? (", " + name) : "");
};

adam.greet("world"); // "hello, world";

This ability to redefine a method is valuable because it makes it possible for plugins to modify the behaviour of an existing code library.

Late Binding and Prototype Chaining

How does late binding work with prototype chaining? Let’s start with a fresh example. First we’ll make a new object adam who introduces himself.

var adam = {
    _name: "Adam";
    greet: function() {
        return "hello. I am " + this._name;
    }
};

Someone named Adam seems like a suitable prototype for all existing people. We can make a constructor function to produce more people.

function Person(name) {
    this._name = name;
}
Person.prototype = adam;

var eve = new Person("Eve");
eve.greet(); // "hello. I am Eve"

Thanks to the combination of late binding and the prototype chain, a change to adam will result in a change to eve instantly. The following could be some plugin for the library that provides the adam object. This redefinition could happen at runtime due to user interaction.

adam.greet = function(name) {
    return "hello" + (name ? (", " + name) : '') + ". I am " + this._name;
};

eve.greet("world"); // "hello, world. I am Eve"

Early Mixins

Another way to create a reusable bunch of code as a library is to provide one object who’s properties can be mixed into another object. This is usually done with an early mixin implementation.

First, a generic function that can mix properties from one object into another object.

function earlyMixin(sink, source) {
    for (var property in source) {
        sink[property] = source[property];
    }
}

Now a object containing methods that would be useful on another object. Here is a library called Speeches.JS.

var speeches = {
    greet: function() {
        return "hello. I am " + this._name;
    },
    farewell: function() {
        return "goodbye. I am " + this._name;
    }
};

Since this Speeches.JS library is already written and well unit tested, we’d like to reuse that code in our code.

function Person(name) {
    this._name = name;
}
earlyMixin(Person.prototype, speeches);

var adam = new Person('Adam');
adam.greet(); // "hello. I am Adam"

Now suppose we have mixed this speeches object into several other objects (like the Person.prototype object.) Also suppose we want to modify the speeches object at some later time and have all objects who’ve had the speeches object mixed into it be updated. This is what a plugin for Speeches.JS might want to do.

speeches.greet = function(name) {
    return "hello" + (name ? (", " + name) : '') + ". I am " + this._name;
};

Unfortunately we cannot do this because the speeches methods have been mixed into the Person.prototype object early (i.e. at the time of mixin.) We still have

adam.greet("world"); // "hello. I am Adam"

Late Mixins

In order to make it possible to modify speeches and have all objects use the modified methods, we need one level of indirection in the mixin process.

function lateMixin(sink, source) {
    for (var property in source) {
        (function(property) {
            sink[property] = function() {
                return source[property].apply(this, arguments);
            }
        }(property));
    }
}

Instead of directly borrowing the methods of the source, the sink is given methods that call the methods of source. This means that the method on source are mixed in late because they are looked up when they are called (rather than when they are mixed in.)

Now we can go through the same example with a different result.

var speeches = {
    greet: function() {
        return "hello. I am " + this._name;
    },
    farewell: function() {
        return "goodbye. I am " + this._name;
    }
};

function Person(name) {
    this._name = name;
}
lateMixin(Person.prototype, speeches);

var adam = new Person('Adam');
adam.greet(); // "hello. I am Adam"

speeches.greet = function(name) {
    return "hello" + (name ? (", " + name) : '') + ". I am " + this._name;
};

adam.greet("world"); // "hello, world. I am Adam"

When adam.greet is called it uses the most recent definition of speeches.greet. Yay! Late mixins have given us the same dynamic power that late binding and the prototype chain give us. This makes a library like Speeches.JS more flexible and opens it up for various kinds of modification at run time.

Not Quite Everything

Late mixins give us some of the power of late binding and the prototype chain but not everything. If we add another method to the speeches object it is not added to the other objects into which speeches has been mixed. There are several ways to accomplish this type of functionality. Something like proxies might be our answer to get closer to real multiple inheritance.

uMVC - A micro MVC framework in JavaScript

2012-10-13T20:00:00Z

I tweeted:

You can write an MVC framework in one hundred lines of JavaScript & write about its effective use for one hundred thousand lines of English.

I wondered exactly how small I could write a respectable MVC framework that included the three fundamental design patterns of the traditional Smalltalk-style MVC: the observer, composite, and strategy patterns.

See the uMVC code on Github.

Hopefully this code is educational for those new to the MVC paradigm. I think this code is something every JavaScript programmer should understand inside out and be able to explain every individual line’s significance to another programmer new to MVC.

If you are looking for a more fully-featured MVC framework that follows the same principles of uMVC to use in real browser applications, I suggest you take a look at Maria.

Less English, more JavaScript

2012-10-13T19:00:00Z

I haven’t written much for my website this year. It wasn’t an accident. I wasn’t too busy. It was a choice. My new year’s resolution for 2012 was to write less English and more JavaScript.

Three quarters of the year is now gone and I feel like I’ve satisfied that resolution with 11 new JavaScript repositories on Github. Most of the work was driven by the development of the Maria framework for writing MVC-style browser application. That particular project has been great fun and satisfying.

Now I feel as through I should tell the world about these projects … but part of me just wants to continue writing more JavaScript.

Organizing Browser Application Files

2012-10-12T23:00:00Z

If you are building a large, one-page browser application with the usual suspects of HTML, CSS, JavaScript, images, etc, you’ll have many files and staying organized is important. Here is a way to organize your files.

General Structure

MyApp/
    Makefile
    README
    etc/
    lib/
    src/
    tst/

Perhaps the first thing you will do when starting the project is fill the lib directory with all the third-party libraries you know you’ll be using. These libraries are dropped into the lib directory without modification. Just plop them there in the same form they are distributed. You aren’t allowed to edit these files. This directory is the only directory where you put files created by a third party.

The src directory contains all of the files that you create and write that will become part of the files downloaded by the browser of a user of your application. These are the files we are excited about writing.

The tst directory contains all the files that test the files in the src directory. These are the files we are not excited about writing.

The Makefile has a default build target that generates the directory called bld which is filled with production-ready files that can be copied to the production web servers. The files in the lib and src directories are combined, minified, compressed, and otherwise mutated to become the files in the bld directory. This target can possibly generate a MyApp.tar.gz file if that is how the distribution to production will be done.

The build process may be guided by data in files in the etc directory. For example, there may be manifest files that state which files are concatenated together during the build and the name of the resulting files. Exactly which files with which data are in your etc directory depend on which tools you are using in your build process.

The Makefile should have a clean target that deletes the bld directory.

The Makefile might have a test target that runs the tests in the tst directory.

The README should at least explain what the targets in the Makefile do and how to run the tests.

You should not need to run make build in order to test your application either with the files in the tst directory or in the browser while developing. You may have files in your etc directory that control how the development environment is configured.

An MVC-style Application

You might be using an MVC framework like Maria to help structure your JavaScript. In this case, there is a natural way to divide your application at a finer scale.

MyApp/
    Makefile
    README
    etc/
    lib/
        maria.js
    src/
        css/
        html/
            index.html
            templates/
        img/
        js/
            bootstrap.js
            controllers/
            models/
            views/
            util/
    tst/

The index.html files is the page that the user loads into their browser to start the one-page application. This may be named something different like myapp.html. This file loads the necessary CSS, image, template, and JavaScript files needed to run the application.

The templates directory contains any HTML templates used by your JavaScript views. These can be compiled to JavaScript and concatenated into one or a few JavaScript files during the build process.

The bootstrap.js file is the one with the call to window.onload that fires up the whole application. It will start the loading of the data from the server, create the model layer, build the views, and add those views to the page so the user can begin interacting with the application.

The controllers, models, and views directories contain the obvious.

The util directory contains utility code that is not specific to any of the model, view, or controller layers. There may be pure functions that make computations with no side effects. You might have some obscure DOM related utilities that you wish were written by a third party for your lib directory but that you have to write yourself for your unique browser scripting requirements.

Mixins and Constructor Functions

2012-04-23T20:16:00Z

JavaScript allows programmers to take properties from one object and mix them into another object. There are several ways to accomplish this mixing and a few of them are explored here.

Observable Mixin

Here is a simple example of the observer pattern that can be mixed into other objects.

var observableMethods = {
    observe: function(observer) {
        if (!this.hasOwnProperty('observers')) {
            this.observers = [];
        }
        this.observers.push(observer);
    },
    notify: function(data) {
        if (this.hasOwnProperty('observers')) {
            for (var i=0, ilen=this.observers.length; i<ilen; i++) {
                this.observers[i](data);
            }
        }
    }
};

It is possible to use the observableMethods function as a observable itself.

observableMethods.observe(function() {
    alert('hi');
});
observableMethods.notify();

A little mixin function to make other things observable.

function mixinObservable(sink) {
    for (var p in observableMethods) {
        if (observableMethods.hasOwnProperty(p) &&
            typeof observableMethods[p] === 'function') {
            sink[p] = observableMethods[p];
        }
    }
}

We can mixin to an person created with an object literal.

var person = {
    name: 'Steve',
    setName: function(name) {
        var oldName = this.name;
        this.name = name;
        this.notify({oldName: oldName, newName: this.name});
    }
};
mixinObservable(person);
person.observe(function(data) {
    alert(data.oldName + ' was renamed to ' + data.newName);
});
person.setName('Sarah');

Alternately we write a constructor function for observable people that we can rename.

function Person(name) {
    this.setName(name);
};

mixinObservable(Person.prototype);

Person.prototype.setName = function(name) {
    var oldName = this.name;
    this.name = name;
    this.notify({oldName:oldName, newName:this.name});
};

We can then make a person and manipulate it.

var person = new Person('Steve');
person.observe(function(data) {
    alert(data.oldName + ' was renamed to ' + data.newName);
});
person.setName('Sarah');

In all of the above code, the three uses of hasOwnProperty are critical to understand.

The first two uses of hasOwnProperty in observe and notify ensure that the object into which the methods have been mixed, will have its own set observers and not share some set of observers with any other object. The unfortunate part is that these checks run every time the observe and notify methods are called. This is inefficient and something we want to fix.

The third use of hasOwnProperty in mixinObservable means that only properties directly on observableMethods will be mixed into other objects. This is important because if we do not use hasOwnProperty then we copy all of the enumerable Object.prototype properties which is either wasteful or will overwrite any custom methods with the same names on other objects.

The mixinObservable function also copies only functions. If this check was not made and someone had observed the observableMethods object itself then the observableMethods.observes array would be copied as part of every mixin and observers would be shared by some observable objects (e.g. observableMethods and Person.prototype in the example above.)

A simpler mixinObservable method could be the following but this could be more difficult to maintain. If more methods are added to observableMethods then they need to be explicitly listed in mixinObservable.

function mixinObservable(sink) {
    sink.observe = observableMethods.observe;
    sink.notify = observableMethods.notify;
}

Fixing the Inefficiency

The inefficiency in observe and notify can be fixed by making a constructor function for Observable objects.

function Observable() {
    this.observers = [];
}
Observable.prototype.observe = function(observer) {
    this.observers.push(observer);
};
Observable.prototype.notify = function(data) {
    for (var i=0, ilen=this.observers.length; i<ilen; i++) {
        this.observers[i](data);
    }
};
Observable.call(Observable.prototype); // optional depending what you want

Now the observe and notify methods of an observable function are more efficient as we know the observers property was created when the Observable constructor function ran.

The last line, Observable.call(Observable.prototype);, is a bit of an unusual one but it makes it possible to observe Observable.prototype just like observableMethods.

A new mixin function.

function mixinObservable(sink) {
    for (var p in Observable.prototype) {
        if (Observable.prototype.hasOwnProperty(p) &&
            typeof Observable.prototype[p] === 'function') {
            sink[p] = Observable.prototype[p];
        }
    }
    Observable.call(sink); // optional depending what you want
}

Mixing into a person created with an object literal just like it was done above. The last line of this new mixinObservable insures the observers property is created.

var person = {
    name: 'Steve',
    setName: function(name) {
        var oldName = this.name;
        this.name = name;
        this.notify({oldName: oldName, newName: this.name});
    }
};
mixinObservable(person);
person.observe(function(data) {
    alert(data.oldName + ' was renamed to ' + data.newName);
});
person.setName('Sarah');

The trick comes when we create a Person constructor function.

function Person(name) {
    Observable.call(this);
    this.setName(name);
};

mixinObservable(Person.prototype);

Person.prototype.setName = function(name) {
    var oldName = this.name;
    this.name = name;
    this.notify({oldName:oldName, newName:this.name});
};

The first line of the constructor function, Observable.call(this);, ensures that each Person object has its own set of observers. Without this call, all the people will share the same list of observers which is the set of observers on the Person.prototype object. If this makes you squint then it is well worth the effort to think about it until it is clear why.

To use some class vocabulary, the first line of the constructor function can be thought of as a super call and that the Person class inherits from the Observable class. Some JavaScript diehards cringe at the mention of this vocabulary but I think the comparison is worth consideration.

Multiple Mixins

Multiple mixins follow the same pattern.

function Person(name) {
    Observable.call(this);
    Common.call(this);
    this.setName(name);
}

mixinObservable(Person.prototype);
mixinCommon(Person.prototype);

// By coincidence mixinCommon also added a notify method which
// clobbered the method of the same name added by mixinObservable.
// Fix this problem making appropriate decisions about how
// to call both.
Person.prototype.notify = function() {
    Common.prototype.notify.call(this);
    Observable.prototype.notify.apply(this, arguments);
};
// ...

Prototype Chaining vs. Mixins

There is one primary difference between prototype chaining and mixins. For example,

function Person(name) {
    Observable.call(this);
    Base.call(this);
    this.setName(name);
}

// chain prototypes so that all Person objects
// inherit from Base.prototype.
Person.prototype = Object.create(Base.prototype);
Person.prototype.constructor = Person;
Base.call(Person.prototype); // optional depending what you want

mixinObservable(Person.prototype);

Now if we add methods to both Base.prototype and Observable.prototype after the above code has executed. Only the method added to Base.prototype will be added to Person objects.

Base.prototype.getId = function() {/*...*/};
Observable.prototype.getObservers = function() {/*...*/};

var person = new Person('Steve');
person.getId(); // ok
person.getObservers(); // error: getObservers not defined

Enjoy your mixins.

Our Backwards DOM Event Libraries

2012-03-03T20:46:00Z

The Browser APIs

A brief review of what the browsers give us to attach event listeners to DOM elements so we can do fancy stuff when the user interacts with the page.

Internet Explorer gives us element.attachEvent allowing us to attach a listener function to an element.

document.body.attachEvent(
    'onclick',
    function() {
        alert('body clicked');
    });

The other browsers give us element.addEventListener. The use with which we are most familiar is supplying a listener function as the second argument.

document.body.addEventListener(
    'click',
    function() {
        alert('body clicked');
    },
    false);

Many JavaScript programmers don’t know that it is also possible to send a listener object as the second argument to addEventListener. When an event is fired, the object’s handleEvent method is called.

document.body.addEventListener(
    'click',
    {
        handleEvent: function() {
            alert('body clicked');
        }
    },
    false);

An important feature of using a listener object is that the function value of it’s handleEvent property is only looked up when the event is fired. This means that if the function value of the handleEvent property changes between events then it is always the current value of the handleEvent property that is called. This is late binding. For example,

var obj = {};

document.body.addEventListener('click', obj, false);

// click body will error in some browsers because
// no handleEvent method on obj

obj.handleEvent = function() {alert('alpha');};

// click body and see alert "alpha"

obj.handleEvent = function() {alert('beta');};

// click body and see alert "beta"

document.body.removeEventListener('click', obj, false);

// click body and see nothing

Cross-Browser Libraries

Our cross-browser applications should not be cluttered with repetitive code to work with the different APIs provided by the different browsers, so we’ve abstracted the different APIs away in event libraries. This has been a very good choice.

Different libraries have different APIs but every library has something like the following.

LIB_addEventListener(
    document.body, 
    'click', 
    function() {
        alert('body clicked');
    });

The JavaScript `this` Wrinkle

A common problem with these library abstractions is when we want a method of an view object to be called when the event is fired. For example, in the following code, the value of this in the handleClick method is the global window object. The alert will show undefined when we may have expected to see the alert show "alpha".

function ViewObject() {
    this.data = 'alpha';
    LIB_addEventListener(
        document.body, 
        'click', 
        this.handleClick);
}
ViewObject.prototype.handleClick = function() {
    alert(this.data);
};

The workaround the libraries have given us (so that we can also still easily remove event listeners) is to specify the object we want as this when the handler is called as an extra argument to the event library function. For example, the alert in this example will show "alpha".

function ViewObject() {
    this.data = 'alpha';
    LIB_addEventListener(
        document.body, 
        'click', 
        this.handleClick,
        this);
}
ViewObject.prototype.handleClick = function() {
    alert(this.data);
};
ViewObject.prototype.destroy = function() {
    LIB_removeEventListener(
        document.body,
        'click',
        this.handleClick,
        this
    );
};

One problem with this API is that the listener function is bound when LIB_addEventListener is called. This causes trouble when the function value of handleClick is changed and then also when an attempt is made to remove the listener.

var vo = new ViewObject();

// click on the body and see alert "alpha"

vo.handleClick = function() {
    alert('beta');
};

// click on the body and still see "alpha"

vo.destroy();

// click on the body and still see "alpha"!

Another problem is that we are writing the program in an object-oriented style but we are focusing on listener functions rather than listener objects. This mismatch is a clue to find a better solution.

A Library API for Listener Objects

Since we are frequently writing our programs in an object-oriented style, it makes sense to write LIB_addEventListener so that it can accept listener objects (as well as listener functions.)

var obj = {
    handleEvent: function() {
        alert('click handler');
    }
};
LIB_addEventListener(document.body, 'click', obj);

Frequently we have one view object handling multiple types of events for various elements. A fourth parameter specifying the method name would allow that easily and still keep late binding.

var obj = {
    handleMouseDown: function() {
        alert('mouse down handler');
    },
    handleMouseUp: function() {
        alert('mouse up handler');
    }
};
LIB_addEventListener(document.body, 'mousedown', obj, 'handleMouseDown');
LIB_addEventListener(document.body, 'mouseup', obj, 'handleMouseUp');

This API still allows for listener functions by looking at the type of the third argument.

LIB_addEventListener(document.body, 'mousedown', function() {
    alert('mousedown');
});

But now there is no need for specifying the this object that will be used when the listener function is called because we have something better suited to the task: listener objects.

Scheme from Scratch - Royal Scheme v0.1 - Integers

2011-07-29T17:50:00Z

It took a while but the plan is back on track. Royal Scheme is a go.

I’ve been picking away at the project at a leisurely pace trying to determine exactly what it will be. Blog articles seem like a great way to keep folks informed about the state of development. Hopefully some folks will want to follow along creating their own implementations again like they did with Bootstrap Scheme. It was a whole bunch of fun.

I think a book format would be a better format for truly documenting the iterative development of a real Scheme interpreter that is implemented in C. I still haven’t found that book and if I was taking a university course then I’d want to take the course that has that book as its primary text. So a lot of what Royal Scheme development will be about is ensuring the order of introducing features is just right and that the concepts underlying the implementation are explained in code comments and in a book. It is a lofty goal. We’ll see how it goes. I’m hoping for feedback from you.

Just as Bootstrap Scheme started with integers, so does Royal Scheme.

$ ./scm
Welcome to Royal Scheme. Ctrl-c to exit.
> 123
123
> -123
-123
> +007
7
> ^C
$

I’ve put the code on github. I’m new to git and github which adds a bit more flavor to the project. You can browse the code at the following address

http://github.com/petermichaux/royal-scheme

and I created a branch specifically for this integers-only version

https://github.com/petermichaux/royal-scheme/tree/v0.1

You can get the code with the following command

$ git clone https://github.com/petermichaux/royal-scheme.git

You should be able to just run make and then the above REPL session example should work.

I’m hoping you will scrutinize the code and really give me grief that I’ve done something silly, stupid, overly complex, have a trailing space on a line, haven’t written a comment where a comment would be helpful, etc. I’m particularly interested in what you think of checking the return value of printf and scm_write in repl. It doesn’t feel right quite to me. Also the overflow checking in scm_read_number happens each iteration which is not as efficient as it possibly could be.

By the way, registration for the Scheme 2011 Workshop will open in August. I’m planning on going and hoping to talk with some people there about Royal Scheme.

Previous article: Introduction

JavaScript is Dead. Long Live JavaScript!

2011-06-25T20:21:00Z

For 16 years, JavaScript has been the language of the web browser. This language has enabled the building of compelling web applications and contributed to the success of the web. Other scripting languages could have filled the role JavaScript does but JavaScript was in the right place at the right time. Microsoft added Basic to Internet Explorer a long time ago but JavaScript was the language in all the browsers and so it won. Since JavaScript has been cross-browser and at least good enough, the browser makers have not needed to add other language interpreters to the browsers themselves.

But we still didn’t choose to use JavaScript. It has been the one option. It has powerful features like closures and we learned to love these features while turning a blind eye to the warty parts of the language. There has even been a lot of apologizing to the programming community along the lines of “Yes we know it is a pretty funky language but please give it a chance. I’m sure you’ll learn to love it.” It shouldn’t be that hard to sell the quality of the language. JavaScript has been described as an experiment that escaped the lab a little too early and we’ve been stuck with the warts ever since.

Still, JavaScript has been a great language. In 2007, Steve Yegge declared JavaScript as The Next Big Language and it has been. Between then and now JavaScript-based web-applications have become bigger and better. With JavaScript’s help, the web has continued to flourish even with the threat of native mobile apps taking over the same space.

In very recent times, JavaScript has been making its most successful attempt at being a server-side language. The Node.js platform, with its non-blocking I/O, may be solving a problem that programmers have needed solved for a long time. JavaScript is the language for Node.js and so JavaScript may go along for the ride to become a successful server-side language after many failed attempts in the past.

Overall, JavaScript has been a wild success. The most popular programming language in the world. But if the browser died today, how much new JavaScript code would be written tomorrow? Most likely JavaScript would become a fringe language overnight. But the browser isn’t dying tomorrow. We will be programming for it for years to come.

As JavaScript has been used for more and larger programs, the warts of the language have become more apparent and caused increasing amounts of grief for many developers. It may come as a surprise that even though I’ve written about JavaScript for years, I’m not a JavaScript fanboy. Most of my JavaScript articles have been about me working through the difficulties of finding a peaceful coexistence with the language. Yes I’ve enjoyed programming in JavaScript and have learned a lot but there certainly have been times when I’ve felt like I’m wallowing in the muck.

One of the most obvious deficiencies in JavaScript is with its user interface: its syntax. The inability to quickly improve its syntax has lead to the language’s downfall.

The Case for Syntax Extensions: Verbose Idioms

Here we look at just four of the many examples where JavaScript’s syntax could be improved to remove verbose idioms from our daily programming existences.

Optional Parameters and Default Values

JavaScript functions can be called with a variable number of actual parameters. This makes some of the formal parameters in the function’s declaration optional. Often times these optional parameters must be set to a default value if no actual parameter is supplied. I’m willing to bet you’ve written and seen plenty of code like the following.

function(a, b, option) {
    option = option || {};
    // ...
}

I have and still write code like this. This code is wrong. If a falsy value is passed to the function for option then the wrong thing happens. We should be writing the following.

function(a, b, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

Although this code expresses the intended thought of setting a default value if an actual parameter for option is not supplied, it is too verbose and less readable. The reader must count to determine which variable is has index 2. Beyond the awkwardness, the correct version is more difficult to maintain. It is easy to produce the following buggy code if the b parameter is removed.

function(a, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

If your application uses optional parameters with default values, some new syntax would be beneficial for you.

function(a, b, option = {}) {
    // ...
}

The addition of this new syntax tunes the language better to your application’s needs.

Let

Does the following buggy code look familiar?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + i);
    });
}

All the elements were the same number?! The solution is to use an immediately evaluated function expression so each alert reports a different number. This is the “let” idiom after Lisp’s various let forms.

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    (function(num) {
        LIB_addEventListener(element, 'click', function(event) {
            alert('I was originally number ' + num);
        });
    }(i));
}

Sure sometimes delegate listeners might be better than the above code but sometimes the above code is the desired idea. In the above case, we are trying to bind the order of the elements when the loop runs. This order could be lost with the delegate pattern if the elements are rearranged in the DOM.

This syntax is particularly awkward because of the distance between the formal num and actual i parameters of the immediate function.

The immediate function could be factored out to another location and called inside the loop.

function attachListener(element, num) {
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + num);
    });
}
for (var i=0, ilen=elements.length; i<ilen; i++) {
    attachListener(elements[i], i);
}

Even with this option, sometimes programmers still use the immediate function because it conveys better their intended message to readers.

If your application uses the let idiom, wouldn’t it be nice to have new syntax for it?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    let (num = i) {
        LIB_addEventListener(element, function(event) {
            alert('I was originally number ' + num);
        });
    };
}

With num and i together it is much easier to read this code and a new scope containing new has been introduced so the closure works properly. Once again, the addition of new syntax can tune the language better to your application’s needs.

Modules

One of the most common idioms in JavaScript programs we all know and love is usually called “the module pattern.” This idiom provides the benefits of encapsulated variables that are private to the module and imparts sanity to our code.

var event = (function() {

    // private variables
    var listeners = [];
   
    function addEventListener(f) {
        listeners.push(f);
    }

    function clearEventListeners() {
        listeners = [];
    }
    
    // ...
    
    // export the module's API
    return {
        addEventListener: addEventListener,
        clearEventListeners: clearEventListeners
        // ...
    };
}());

The goal of encapsulation here isn’t security. It is to ensure that other developers keep their dirty, monkey-patching hands off your module’s data.

The exporting can be done a few ways but no matter which way there is some boiler plate.

Importing is verbose also

(function() {

    // import desired properties of the event module
    var addEventListener = event.addEventListener;
    var clearEventListeners = event.clearEventListeners;
    
    // ...
}());

Some new syntax would be nice to convey the intent of the module pattern better.

module event {
    
    // private variables
    var listeners = [];
   
    export function addEventListener(f) {
        listeners.push(f);
    }

    export function clearEventListeners() {
        listeners = [];
    }
    
    // ...
}

(function() {

    import event;
    
    // ...
}());

The module pattern is almost everywhere and some new syntax to better express this idiom would better tune the language to all of our applications.

Inheritance

These idiom examples have been growing in how they each span an increasing number of lines of code. The JavaScript idiom that potentially spans the most lines of your program may be the inheritance idiom.

function Employee(first, last, position) {
    // call the superclass constructor
    Person.call(this, first, last);
    this.position = position;
};
// inherit from Person
Employee.prototype = Object.create(Person.prototype);
Employee.prototype.constructor = Employee;

// define an overridding toString() method
Employee.prototype.toString = function() {
    // call superclass's overridden toString() method
    return Person.prototype.toString.call(this) +
           ' is a ' + this.position;
};

What a mess. Yes JavaScript makes single inheritance like this possible by linking prototypes but it takes a lot of code to manually make super things happen they way you might like inheritance to work.

If there could be a maintenance nightmare that is it. The strings “Person” and “Employee” are sprawled throughout the code for the Employee “class”.

If classes with inheritance are a big part of your application, some syntax would really help clean up the code. Perhaps something like the following.

class Employee extends Person {
    constructor(first, last, position) {
        super(first, last);
        public position = position;
    }
 
    update(camera) {
        return super.update() + ' is a ' + position;
    }
}

That is a major improvement.

Learning from Idioms

These common idioms make it clear that JavaScript could use some new syntax for several reasons. The ability to do what we want is usually in JavaScript somewhere. The verbosity of the idioms is sometimes too much. We cut corners. Sometimes we avoid certain algorithms because the idioms are too verbose. The idioms are not self explanatory. They are inside secrets of the community and the intent is not easily recognized by outsiders.

The ECMAScript committee has recognized that the above idioms, and others idioms, are common across a wide variety of applications. There are proposals for all of these syntax cases in Harmony. Some of them may make it into the next version of ECMAScript and into the browsers for your use. If new syntax gets there eventually then you can use use it.

Idioms may have emerged in your application that do not appear in a wide variety of applications. For example, Node.js’s non-blocking I/O and heavy reliance on callbacks will undoubtedly result in idioms that do not appear in browser scripts. Syntax specific to just your applications will likely never make it into ECMAScript.

If you would like to use specialized syntax for the general idioms like those shown above or you would like syntax for your own idioms, what can you do?

If Only We Had Macros

Lisp languages have had full-blown macros for decades. Through macros, Lisp gives programmers the ability to tune the language’s syntax to best match their own applications. Because of its macros, Lisp has been described as “the programmable programming language.” Powerful stuff.

Lisp’s s-expression syntax, you know, the syntax with all those parens, gives the language a special property called homoiconicity. It roughly means the syntax of the language is also the syntax of its data structures or that a program’s parse tree uses the languages data structures. This homoiconicity makes Lisp’s macros possible.

JavaScript doesn’t have macros. A major reason for this is that adding macros to languages with C-like syntax, languages that are not homoiconic, is still a research topic. Excerpts from a short conversation on Twitter with littlecalculist, Dave Herman, Ph.D., ECMAScript committee member, and Mozilla Researcher:

@petermichaux

I believe @littlecalculist knows more about the research and possibilities for macros in ECMAScript. I’d like to know more also.

@littlecalculist

I have thoughts on it for sure. But macros for non-sexp languages is still very much a challenging research topic

@petermichaux

[...] We’ll turn blue waiting for macros.

@littlecalculist

Might I suggest you keep breathing? ;-) Seriously, I do hope to try, but trust me, macro system design is hard.

The message is pretty clear. JavaScript macros are not just around the corner.

Harmony Syntax ETA

Perhaps the syntax extensions in Harmony are all you dream of and more. If Harmony becomes ECMAScript 6 and ECMAScript 6 becomes ubiquitous then you’ll be all set. So all you need to do is wait...patiently.

First, let’s look at browser adoption. Unfortunately I’ll pick on Internet Explorer a bit, which has almost become a cliche, but not because I have something against the Internet Explorer development team at Microsoft or the newest versions of Internet Explorer. It is necessary to look at this browser because it is perhaps the most important case study for estimating when features will be available for all visitors to your web site.

As of May 2011, w3schools, which has relatively tech-savvy visitors, reports Internet Explorer 6 still has 2.4% market share. Net Market Share reports Internet Explorer 6 still has 10.36% market share. Your site probably has a market share somewhere between those two numbers but this browser is still hanging on even though it was superseded by Internet Explorer 7 in November 2006. How many people are still using Internet Explorer 6 or 7? The w3schools site shows 7.7% and Net Market Share shows 18.2%. These browsers just aren’t going away fast enough. A publicly available site (e.g. Amazon) cannot afford to ignore market share numbers this large.

There is no point in spending any energy moaning that users should upgrade their browsers or that “IE should die!” It won’t happen. I don’t know if it is true but someone once said to me “Internet Explorer users upgrade their browser when they upgrade their hardware.” For the past few years, hardware has certainly become sufficient that people don’t need to upgrade anything to use email, Facebook, Twitter, etc.

Suppose your web app is sufficiently advanced that you’ve decided that you only care about users with “modern” browsers. Google Apps recently announced that on August 1, 2011 they will stop supporting Internet Explorer 7. That is almost 5 years after Internet Explorer 7 was released.

Now think about this: Internet Explorer 10 is not out yet but, of course, even it won’t have Harmony’s syntax extensions. Let’s estimate that Harmony is approved as ECMAScript 6 in mid-2012 and Internet Explorer 11 is released in early 2013 with support for all of Harmony’s syntax. Five years after that, in 2018, the Google Apps team can drop support for Internet Explorer 11 and finally use Harmony syntax freely. (On August 1, 2011, they are also dropping support for the four-year-old Safari 3 and two-year-old Firefox 3.5 so the waits are still long-ish for other browsers too.)

Amazon developers might need to wait an additional 5 years before they can use Harmony syntax. That’s 2023!

Will you be satisfied waiting 7-12 years before you can start using syntax that would be helpful developing your web apps today? Being more optimistic, even if the wait is just 5 years, will you wait?

JavaScript is Dead.

Cause of death: semicolon cancer.

Perhaps due to JavaScript’s syntax alone, JavaScript does not have macros now and won’t have them soon if ever. Millions of programmers use JavaScript now and plenty of them are tired or tiring of the verbose idioms confronting them daily. They want new syntax now and won’t wait. For this growing group of developers, JavaScript the source code language is dead.

You had a good reign, JavaScript. We had some good times and wrote some cool apps together. May you rest in peace.

Long Live JavaScript!

Programmers like to control their own destiny and they are taking action. You can have all the new syntax you want for your browser scripts, right now, if you write in another source language and compile to the ECMAScript 3 dialect of JavaScript for the billions of browsers in the wild. By compiling to ECMAScript 3 you are completely freed from JavaScript’s syntactic evolution. As an added bonus, you can even fix some of JavaScript’s semantic gotchas with a sufficiently sophisticated compiler. JavaScript’s new life is as a compilation target.

Languages that Compile to JavaScript

There have been compilers to JavaScript for years now. In 2007, I started collecting a list of languages with compilers to JavaScript. There were JavaScript extension languages: the now-defunct ECMAScript 4, Narrative JavaScript, and Objective-J. There were pre-existing languages: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell, etc. There were even brand new languages HaXe, Milescript, Links, Flapjax that were designed to address web programming needs.

Of these compiler projects, Google’s GWT Java-to-JavaScript compiler has probably been the most successful but I don’t see programmers who first learned a language other than Java rushing to use Java as their source code language. In fact, none of these compiler projects have accrued a significant long-term user base. At least in the parts of the web that I frequent, with the exception of GWT, it is rare to read about programmers using these compilers for any real projects. There are several legitimate reasons not to use one of these compilers.

Imagine you build a big project using one of these compilers and part way through find a bug in the compiler. The one maintainer of the compiler may have lost interest or time. Do you want to maintain a compiler? Does anyone on your team have the skills to do that? That ulcer is going to get pretty big while you prepare to explain to the CEO that you now need to rewrite the UI in JavaScript.

Just the thought of debugging compiled code when a production bug is filed makes my stomach churn. Core dump. What line number in the source code matches the line number Firebug is reporting for the compiled code? HURRY! That bug needs to be fixed now!!!!

You’ve used Objective-J for a big project and now you need to hire a new good programmer. What are your chances of finding the right person? They are probably very low. Just finding an available JavaScript programmer is difficult enough. If you use one of these alternate languages, it is very likely you’ll need to train each new person you add to your team.

Even without these compiler projects being wildly successful, the list of languages that compile to JavaScript has continued to grow. There is no doubt that writing a to-JavaScript compiler is a very cool project. Please pay me to write one.

There is one notable new entry in the list of languages that compile to JavaScript that is actually causing a big stir and is possibly changing the game for good.

CoffeeScript

I can tell you right now, I don’t know why CoffeeScript has the magic combination of features to garner the attention it has when other projects have failed. Significant whitespace and arrow function syntax. My gut reaction is yuck. There is plenty of things to like: default parameter values, rest parameters, spread, destructuring, fixing the whole implied global mess, even classes if you’re into that kind of thing and more. Many of CoffeeScript’s features are part of Harmony and so may be in browsers sometime in the future but if you use CoffeeScript then you can have them now. There is nothing like instant gratification.

Programmers are bursting with affection for CoffeeScript.

@pyronicide

Being able to use default values for function arguments in #coffeescript makes me immensely happy.

@_jdpage

CoffeeScript is wonderful. Now I am spoiled and will complain whenever I have to write JavaScript instead.

At the TXJS 2011 conference, Douglas Crockford apparently shared that he thinks “CoffeeScript is clearly good stuff.”

There is one aspect of the CoffeeScript project that I really like and it is summed up by the following two quotations. The first comes from Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development.

@trevorburnham

[...] It’s not about turning JS into Ruby/Python; it’s about having a syntax better suited to JavaScript’s inner goodness.

The second is from The Little Book on CoffeeScript.

CoffeeScript neatly sidesteps these [JavaScript issues], by only exposing a curated selection of JavaScript features.

The attitude expressed in these quotations really is great and genius marketing too. It is not CoffeeScript verse JavaScript. It is CoffeeScript enhancing the JavaScript programming experience. Could some different syntax and a restricted subset of JavaScript’s features really be better than plain old JavaScript?

Douglas Crockford seems to think so. For years, his JSLint has been hurting our feelings and demanding that we use very specific whitespace and syntax and that we avoid dangerous JavaScript features. Source code that passes JSLint has access to a true subset of JavaScript: the subset that he calls “the good parts.” This dialect of JavaScript deserves a name. Maybe GoodScript? After all, you are only allowed to use JSLint for good and not for evil.

The ECMAScript committee also thinks this is a good idea. The "use strict" pragma introduced in ECMAScript 5 not only restricts some language features like with, strict mode even changes/fixes the semantics of some parts of the language. Because of the semantic changes, ECMAScript 5 strict is a different language or at least a different dialect than ECMAScript 5 non-strict.

CoffeeScript, GoodScript, and ECMAScript 5 strict share common goals of keeping you away from the dangerous parts of JavaScript while giving you access to the valuable, safe parts. Each enforces these goals differently but they are enforced one way or another. You don’t get new syntax with GoodScript. It is already JavaScript and ready for the browser. You don’t get to use ECMAScript 5 strict because it is not available in all browsers yet and won’t be for years.

So CoffeeScript seems to be targeting a particular need of web development and maybe that is something other to-JavaScript compilers haven’t done or haven’t done well before.

CoffeeScript is also a reasonably thin skin over JavaScript. One consequence of this is that the compiled JavaScript code is reasonably easy to read and not brutal to debug (so I’m told.) This reduced debugging fear is contributing to interest in CoffeeScript.

CoffeeScript almost feels like a set of macros for writing JavaScript programs.

Since CoffeeScript compilers are in the hands of developers rather than the visitors to sites, you control which version of CoffeeScript you are using. You can upgrade at will. This also means CoffeeScript does not need to be standardized and go through the subsequent painfully slow growth of a standardized language. CoffeeScript can grow at the rate of its community’s imagination and desire. JavaScript standardization was essential to the success of the web but the same constraints do not apply to CoffeeScript.

Well then I’m going to invent my own language.

You can do this and it would be a great exercise. You’ll be able to call yourself a compiler writer which is pretty darned prestigious.

The danger of inventing your own language lies in the thinking that you can do better than JavaScript has done in the long run. Language design is hard and I bet your language will grow its share of unsightly hairs. Maybe not as many hairs as JavaScript but still. CoffeeScript hasn’t hit puberty yet but there are already signs that hair follicles may exist.

@maxsamukha

CoffeeScript: The way variables in outer scopes can be accidentally overwritten is fishy. How bad is it in practice?

You were so proud that your simple, readable compiled code was easy to debug. That will become harder as you realize the compiled code’s semantics aren’t quite what they were supposed to be in corner cases.

Idioms will appear in your language and someone will fork your compiler to do away with those idioms (unless your language happens to have macros.)

Enough with this nay saying. Go and write your own language right now. You’ll be a better programmer for it.

What’s missing from JavaScript the target language?

JavaScript is embarking on a new life as a compilation target. It is a capable target for many language features but it could use improvement. In his JSConf.US talk, Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.

Compiled JavaScript can run slower than hand-written JavaScript just like compiled C can be slower than hand-written Assembly (though not always.) Some inefficiency in compiled JavaScript is tolerable because JavaScript virtual machines are fast and the DOM is the bottleneck anyway. That said, some potential source code languages have semantics sufficiently far from JavaScript’s semantics that the compiled code is so inefficient that it cannot realistically be used in production web apps. There are already features in Harmony that will enable some of these languages to be compiled to efficient code and thus make these viable source code languages.

Proper Tail Calls

Programs in Lisp languages depend heavily on recursive calls to properly tail recursive procedures. The proper tail calls proposal in Harmony will allow these programs to be compiled to JavaScript without the inefficient trampoline technique currently necessary to avoid overflowing the call stack. Awesome! Let’s look at that in a bit more detail.

The following JavaScript is an example of mutually recursive functions which would work fine in Lisp but since JavaScript currently does not have proper tail calls, will overflow the JavaScript call stack when number is large.

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return isOdd(number - 1);
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return isEven(number - 1);
    }
}

isEven(100000); // InternalError: too much recursion

In the above code, a call to isEven(100000) isn’t complete and removed from the call stack until isOdd(99999) returns which isn’t complete and removed from the call stack until isEven(99998) returns and so on. That’s a lot of calls on the call stack! And there is no need for them all to be on the call stack. isEven(100000) doesn’t have anything intelligent remaining to do once it calls isOdd(99999) because the call to isOdd(99999) is the very last thing in isEven(100000). The call is said to be in tail position. isEven(100000) is just waiting to return the value returned by isOdd(99999) and a clever language can just pop isEven(100000) off the call stack and replace it with the call to isOdd(99999) thus saving space on the call stack.

With trampolines we can ensure that even in JavaScript the call stack doesn’t grow large. The following is just a sketch of how trampolines might be implemented and how isEven and isOdd might be compiled for a JavaScript interpreter that doesn’t have proper tail calls.

function bounce(ret) {
    while (typeof ret === 'function') {
        ret = ret();
    }
    return ret;
}

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return function() {
            return isOdd(number - 1);
        };
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return function() {
            return isEven(number - 1);
        };
    }
}

bounce(function() {return isEven(100000);}); // true

You can see the extra overhead of the bounce function which implements the trampoline calls is quite onerous. It creates closures for each continuation, doubles the number of calls, and must examine the returned value after each bounce; however, isEven(10000) does complete and is removed from the callstack before isOdd(99999) is called. The full computation completes in constant call stack space.

The bottom line is trampolines incur too much overhead. They incur so much overhead that when Rich Hickey created Clojure, his Lisp for the JVM, he decided his language could not have proper tail calls because trampolines were too expensive. That must have been a painful decision for someone who loves the Lisp family of languages.

The good news is that the ECMAScript committee has recognized this deficiency in JavaScript and has added proper tail calls to Harmony. This will benefit programmers writing directly in JavaScript and developers of to-JavaScript compilers.

Lambdas

Another strawman proposal not yet promoted to Harmony is the Block Lambda Revival which combines some new syntax with a new language construct called a lambda. A lambda is a callable thing, like a function, but it obeys Tennent’s Correspondence Principle. Tennent’s Correspondence Principle states that wrapping an expression or block of code in an immediate lambda should not change the meaning of that wrapped code. JavaScript functions are not lambdas and do not obey Tennent’s Correspondence Principle. For example,

function one() {
    return 1;
}

one(); // 1

is not the same when the return line is wrapped in an immediate function

function one() {
    (function() {
        return 1;
    }());
}

one(); // undefined

The syntax of the block lambda proposal for a lambda that takes two arguments and sums them is {|a, b| a + b}

Using the syntax of the block lambda proposal we can wrap the return line in an immediate lambda without changing the meaning.

function one() {
    ({||
        return 1;
    }());
}

one(); // 1

Thanks to lambdas obeying Tennent’s Correspondence Principle, the return still means return from the function one.

You may ask “Who cares about this computer science-y stuff?” to which I reply “Did any of that macro business seem useful?” because lambdas are a fundamental building block in the code generated by many macros. And since lambdas play nicely with JavaScript’s return, arguments, and this, lambdas would be a valuable addition to the language for compiler writers.

I’m focusing on the JavaScript-as-a-target aspect of the block lambda proposal. If you plan on writing in JavaScript forever after, the proposal has other benefits for you too that don’t matter to compiler writers.

The block lambda strawman has not yet been promoted to Harmony and so currently doesn’t have a path into ECMAScript 6 and browsers around the world. The standardization process is slow. Maybe there will be another decade stall in evolving the language like there was after ECMAScript 3. Maybe the next edition of ECMAScript will be the last edition. Better to get the best stuff in there than hope to get it in later. If you care about the future of JavaScript and think lambdas would be a benefit to the language then let the ECMAScript committee know by sending a message to the es-discuss mailing list in support of the block lambda proposal. Powerful, orthogonal language features like tail calls and lambdas which have no efficient workarounds may be the most important additions in the next edition of ECMAScript.

What’s missing from the browser?

The browser can help JavaScript succeed in its new life as a compilation target. The browser interprets compiled JavaScript and complains when the compiled code has an error. The error messages contain line numbers in the compiled code but you want to know the line number in source code.

The Mozilla crowd has an open ticket and a dev tools project to ease debugging source code by mapping compiled code lines to source code lines. Since you control the browser in which you primarily develop and test, you can use this feature as soon as it is ready.

Somewhere I read that the Webkit folks are developing similar source code debugging assistance but I cannot find any concrete evidence.

Polyglot

JavaScript’s monopoly in the browser has meant front-end programmers all speak the same language. This has given the community a lingua franca enabling good communication and code sharing. We are now headed for a polyglot future where you choose the language(s) you want to learn and use for developing browser applications. Maybe you are only using a few JavaScript language extensions via Traceur and compiling templates to JavaScript with Mustache. This still means that the CoffeeScript programmer won’t understand your source code immediately.

This divergence was inevitable as it has happened on all previously successful platforms. There have been multiple languages for building native applications almost forever. C is still common but C++, Objective-C, and many other languages are available. The JVM was intended to run programs written in Java but clever developers have added other languages like Clojure and JRuby as options. Microsoft recognized what seems to be a human psychological need for a variety of languages and developed its .NET CLR platform for multiple languages from the beginning. Programs written in Basic, C#, IronPython, etc can all be run on the CLR.

Barriors to communication in the front-end community are not new anyway. A developer using Dojo cannot immediately understand the source code of an application written with jQuery or YUI. There is a plethora of libraries, some very different, that add the ideas of class-based inheritance to JavaScript. So we already have our barriors even within JavaScript.

Having multiple source languages will increase the barriers in our community. Programmers will still need to know JavaScript, at least for a while, but in a few years they may know other source languages better then they know JavaScript.

Choice is a blessing and a curse.

Summary

It is great having the opportunity to watch JavaScript’s transition to a new life as it happens. It’s impossible to say which languages will end up winning market share in the to-JavaScript compilation but it is sure to be interesting. CoffeeScript is gaining momentum now but I think many other successful source code languages will follow.

What do you think will happen?

SICP Classes for JavaScript

2011-06-05T11:56:00Z

Warning: This article is intended for JavaScript programmers. Parens are coming but only briefly and you can handle it and it will be good for you.

In Structure and Interpretation of Programming Languages Second Edition (SICP) on page 182, the authors introduce the idea of message passing with the following example in Scheme of a complex number constructor function.

(define (make-from-real-imag x y)
  (define (dispatch op)
    (cond ((eq? op 'real-part) x)
          ((eq? op 'imag-part) y)
          ((eq? op 'magnitude)
           (sqrt (+ (square x) (square y))))
          ((eq? op 'angle) (atan y x))
          (else
           (error "Uknown op -- MAKE-FROM-REAL-IMAG" op))))
  dispatch)

The important part to note here is that the value returned by the make-from-real-imag constructor function is actually a dispatch procedure that you can call with a message argument. You can send messages to get the real part or magnitude of the complex number.

(define c (make-from-real-imag 3 4))
(c 'real-part) ; 3
(c 'imag-part) ; 4
(c 'magnitude) ; 5
(c 'angle)     ; 0.927295218001612
(c 'asdf)      ; ERROR: Uknown op -- MAKE-FROM-REAL-IMAG: asdf

Let’s see what the above code looks like in JavaScript, our lingua franca.

function makeFromRealImag(x, y) {
    function dispatch(op) {
        switch (op) {
            case 'realPart': return x;
            case 'imagPart': return y;
            case 'magnitude':
                return Math.sqrt(x*x + y*y);
            case 'angle': return Math.atan2(y, x);
            default:
                throw 'Unknown op -- makeFromRealImag: ' + op;
        }
    }
    return dispatch;
}

var c = makeFromRealImag(3, 4);
c('realPart');  // 3
c('imagPart');  // 4
c('magnitude'); // 5
c('angle');     // 0.9272952180016122
c('asdf');      // "Unknown op -- makeFromRealImag: asdf"

Now this probably doesn’t look like any object-oriented JavaScript you’ve seen before but it illustrates an important point. In JavaScript, we can represent the idea of an object as a function of its messages. The constructor function returns a dispatch function that you wrote that can dispatch any message any way that you want it to. This immediately gives you Spidermonkey’s __nosuchmethod__, Smalltalk’s doesNotUnderstand, and Ruby’s method_missing. Powerful stuff but unfortunately the JavaScript code above runs very slowly. We can move towards a faster and more familiar JavaScript style.

SICP page 223, introduces the idea of mutable objects but the most interesting point is the variation on the dispatch procedure.

(define (make-account balance)
  (define (withdraw amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds"))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m)
    (cond ((eq? m 'withdraw) withdraw)
          ((eq? m 'deposit) deposit)
          (else (error "Unknown request -- MAKE-ACCOUNT"
                       m))))
  dispatch)

(define account (make-account 10))
((account 'deposit) 5)  ; 15
((account 'withdraw) 3) ; 12

Converting this to JavaScript we have the following.

function makeAccount(balance) {
    function withdraw(amount) {
        if (balance >= amount) {
            balance = balance - amount;
            return balance;
        }
        return "Insufficient funds";
    }
    function deposit(amount) {
        balance = balance + amount;
        return balance;
    }
    function dispatch(m) {
        switch (m) {
            case 'withdraw': return withdraw;
            case 'deposit': return deposit;
            default:
                throw "Unknown request -- makeAccount: " + m;
        }
    }
    return dispatch;
}

var account = makeAccount(10);
account('deposit')(5);  // 15
account('withdraw')(3); // 12

The way the dispatch function works for accounts is quite different than in the complex numbers case. In the case of complex numbers, when a message was sent to the dispatch function, it executed the associated operation (i.e. the method) immediately. In contrast, the account dispatch function returns the method associated with the message and that method can then be called.

This is very similar to how JavaScript’s reciever.message(arg) syntax works and we can move to a more familiar object-oriented JavaScript style.

function makeAccount(balance) {
    function withdraw(amount) {
        if (balance >= amount) {
            balance = balance - amount;
            return balance;
        }
        return "Insufficient funds";
    }
    function deposit(amount) {
        balance = balance + amount;
        return balance;
    }
    return {
      withdraw: withdraw,
      deposit: deposit
    };
}

var account = makeAccount(10);
account.deposit(5);  // 15
account.withdraw(3); // 12

In this last version, we’ve stopped writing our own dispatch logic and use JavaScript’s built-in property lookup. This increases speed significantly. We’ve lost the ability to do the __noSuchMethod__ type of dispatching when using standard ECMAScript but that doesn’t seem to be commonly useful anyway.

For the well-read JavaScript programmers out there, you may recognize this last version as durable objects from Douglas Crockford’s book JavaScript: The Good Parts.

I find it interesting that the word “inheritance” does not appear in SICP’s index even though the book goes on to implement complex programs like language interpreters and compilers in a message passing style. That shows this simple style of object-oriented programming can take you far.

The moral of the story is that old books are worth reading and can change the way you program today. You can even read SICP for free.