It All Comes Back Around to the for Loop

Growing up my dad's favorite movie was I, Robot. "It all comes back around to I, Robot" he'd often say when other movies touched on similar themes or if interactive technology got a little too smart.

It's an adage that I've never forgotten and one that I also often find myself repeating. But why I, Robot? What is it about that story that make it so easy to refer to over and over again?

Perhaps it's a just a good allegory - a cautionary tale for the future of machine learning in a world that seems to get closer and closer to a robot revolution everyday (looking at you, Alexa). But - and before this becomes a book report - I'd like to think that the pervasiveness of this story (at least in my and my Dad's lives) really goes back to the fact that Asimov's Three Laws of Robotics raise an essential and basic ethical question that is so simple it can be applied over and over again in so many great stories: can morals be taught or - in this case - programmed? In fact, I, Robot is great to refer back to over and over again because it functions (for me at least) as a gateway to understanding and talking about more complex moral and philosophical concepts.

Or maybe it's just that anyone can find a way to bring up their favorite movie?

Either way, this blog post is meant to address what I see as the I, Robot of programming: the for Loop. More than anything else, this is a love letter to the simple for loop and how it has helped me work through so many puzzles as a brand new programmer.

So why the for loop?

First of all, this is not a post about choosing the for loop over the while loop. The while loop is great for when you don't know what your end point will be yet. I'm talking about choosing the simple for loop over some of its more advanced cousins including: the for...of loop, the for...in loop, and the array iterator method forEach().

There are two reasons why I always go back to the simple for loop when I am stuck. The first is that I know the simple for loop will always work. If I'm dealing with a more complex problem, I always start with a regular old for loop to get to a working solution. After I have a working solution, I'll look to refactor my code to include another version of the for loop that might be more suited to the task at hand.

The second reason is that the built-in iterator variable is always a number and numbers are easier to manipulate than other data types.

For example, let's look at an array of strings: const myWords = ["dog", "cat", "cow", "pig", "chicken", "fish"];

Say that we want to write a loop that will console.log each word of the array. Easy. Each element in the array will be accessed and used once:

for (let word of myWords) {
   console.log(word);
}

But now let's say we want to access another element of our array inside of our loop. What if I wanted to write a loop that joined every other word together. If we were to start off with a for...of loop, we'd have to define the other element we need in terms of the position of the current element in our iteration or add in a counter variable (essentially making it like a regular for loop anyway). For the sake of argument lets look at the former:

for (let word of myWords) {
   console.log(word + myWords[myWords.indexOf(word) + 2]);
}

Ew. Not only is that not great to write out, it doesn't leave us with very many options when we encounter the fact that the loop will keep executing even after we run out of words to concatenate. When we execute the code above we get:

dogcow
catpig
cowchicken
pigfish
chickenundefined
fishundefined

Not exactly what we're going for. If we had just started from a regular for loop, not only would it be easier to access the other elements in the array by defining their position relative to i, but also we'd be able to correct our "chickenundefined" problem no problem:

for (let i = 0; i < myWords.length - 2; i++) {
   console.log(myWords[i] + myWords[i + 2]);
}

Much better. Having the ability to manipulate the end point of the loop and use the iterator/counter variable gives us so much more flexibility. I find this flexibility to be so helpful when working through a new problem.

As I've gotten more fluent in JavasScript, it's been easier to tell more immediately which type of for loop is necessary and most efficient in a given scenario (psuedocoding helps!), however I find myself always returning to the familiarity and flexibility of the basic for loop to gain a little bit more understanding.

It all comes back around to the for loop.