Doing a bit of testing last week, I have found out that the source code for the Game Of Life JavaScript Implementation is not working with Internet Explorer 7 (IE7).

It turns out that IE7 doesn’t support the forEach construct, and in while rewriting it, I noticed how the code becomes so much uglier and less readable, which led me to think about the programming language evolution.

Take a moment to compare the following two excerpts:

_.neighbours.forEach(function (neighbour) {
	sum += +neighbour.alive;
});

versus

for (var i = 0; i < _.neighbours.length; i++) {	
	sum += +_.neighbours[i].alive;
}

Sometimes, the syntax changes can lead to huge improvements in coding and readability.

One great example is JavaScript’s forEach.

Now, while this might not seem like a big difference, I think it’s HUGE.

Not only we need to introduce a variable to iterate, but we also need to access the array itself. This takes the focus away from the primary concern, which is the current element that we want to work with.

It is so much nicer to work with the current member of the array instead of focusing on _.neighbours in the loop.

Now consider a more complex example:

_.cells.forEach(function (row, i) {
    row.forEach(function (cell, j) {
        neighboursY = neighbourIndexes(j);
        neighbourIndexes(i).forEach(function (x) {
            neighboursY.forEach(function (y) {
                // this line
                cell.neighbours.push(_.cells[x][y]); 
            });
        });
    });
});

versus

for (i = 0; i &lt; size; i++) {
    for (j = 0; j &lt; size; j++) {
        indexesX = neighbourIndexes(i);
        indexesY = neighbourIndexes(j);
        for (k = 0; k &lt; indexesX.length; k++) {
            for (l = 0; l &lt; indexesY.length; l++) {
                // against this
                _.cells[i][j].neighbours.push(_.cells[indexesX[k]][indexesY[l]]);
            }
        }
    }
}

See the difference? In the second excerpt, I feel like I can’t see the tree from the forest. :)

Another great thing is that the syntax enables the easy refactorization, just take out the function, whereas you would have to rewrite the code.

All this points to me that the evolution of programming languages is a very good thing in the means of the way we see and work with the code.

Published by Bojan Bjelić

Working hard on bunch of stuff, positive future above all. I'm blogging mostly about software, productivity and digital world.

Join the Conversation

2 Comments

  1. for each … in is not a standard construct in JavaScript, it is an extension implemented by Mozilla.
    I would not expect it to work in any non-Mozilla context (Safari, Internet Explorer, Chrome, Opera, iCab, etc.).

    Please see
    https://developer.mozilla.org/en/JavaScript/Reference/Statements/for_each…in

    and note that for…in is a standard construct that could be used instead, as long as care is taken to limit property search(es) to the current object only–don’t walk the prototype chain. Use the hasOwnProperty() method to do the limiting. E.g.,

    // make a global callable function reference to a ‘known good’ version.
    // woe to you if you choose to alter Object’s prototype!
    var HOP=Object.prototype.hasOwnProperty;


    var p; // property index in the object of interest
    for ( p in neighbour ) { if ( HOP.call(neighbor, p) {
    // now we know that property p is intrinsic to the object neighbor,
    // not one that is inherited via the prototype chain
    }}

    see https://developer.mozilla.org/en/JavaScript/Reference/Statements/for…in
    and http://javascript.crockford.com/
    and http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

    In any event, I hope the rewrite of Life is going well!

    Cheers,
    =Aaron

Leave a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.