Vincit omnia veritas. Truth conquers all.

Evolution Of The JavaScript Loop

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.

Here’s an excerpt for comparison:

// in case you're wandering:
// GOOD
_.neighbours.forEach(function (neighbour) {
	sum += +neighbour.alive;
});
// BAD
for (var i = 0; i < _.neighbours.length; i++) {
	sum += +_.neighbours[i].alive;
}

Sometimes, the way the syntax is changing 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.

I prefer to just work with the current member of the array instead of focusing on _.neighbours in the loop.

Now consider the following more complicated example:

_.cells.forEach(function (row, i) {
	row.forEach(function (cell, j) {
		neighboursY = neighbourIndexes(j);
		neighbourIndexes(i).forEach(function (x) {
			neighboursY.forEach(function (y) {
				cell.neighbours.push(_.cells[x][y]); // check this
			});
		});
	});
});
for (i = 0; i < size; i++) {
	for (j = 0; j < size; j++) {
		indexesX = neighbourIndexes(i);
		indexesY = neighbourIndexes(j);
		for (k = 0; k < indexesX.length; k++) {
			for (l = 0; l < indexesY.length; l++) {
				_.cells[i][j].neighbours.push(_.cells[indexesX[k]][indexesY[l]]); // against this
			}
		}
	}
}

Do you 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.

Bojan Bjelić

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

More Posts - Website - Twitter - Facebook - LinkedIn - Google Plus - Flickr

2 Responses to “Evolution Of The JavaScript Loop”

  1. Aaron Sawyer says:

    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 Reply


× 2 = 6