Posted on Oct 14, 2019

Functional Basics #1: Map

#beginners #functional

Welcome! This is the first of a mini-series of articles which I hope will shed a little light on 'functional' programming. It's intended for those who have a knowledge of fundamental coding techniques, and are looking for the next steps to refining their code. Sounds like you? Read on!

In the beginning...

Beginners to coding are often taught the style of coding referred to as 'imperative' style, in which code is a sequence of explicit instructions which lay out every step of the program from start to finish. This is fine, and it works, but one issue with this style is that writing each step of code explicitly can result in a lot more lines of code, and more lines of code means more potential places to introduce mistakes and bugs. Enter...

Functional Programming?

If you haven't heard this term before, don't worry, it's exactly as it sounds - it's the technique of building programs using functions as the basic building blocks, and joining those blocks together in different ways to produce the desired result. This results in a different style of code, known as 'declarative' style, in which code merely describes how a program will execute, rather than explicitly listing every instruction. This generally results in code which is more concise, and more robust.

The first technique of functional programming that many will encounter, and the subject of this article, is...

Map

So what is map? We can describe map as ‘taking an array, doing something with each element, and ending up with an array of the results’. First, let's look at how we might do that with a for loop.

In this example, we have an array of numbers and we want to double each number in the array:

let myArray = [2, 3, 4]

for (let i = 0; i < myArray.length; i++) {
  myArray[i] = myArray[i] * 2
}

// myArray: [4, 6, 8]

This works fine, but we can improve it. If we were doing a calculation more complicated than multiplying a number by 2, we might want to tidy up our for loop by moving the calculation into its own function. Let's do that by creating a double function:

const double = num => num * 2

let myArray = [2, 3, 4]

for (let i = 0; i < myArray.length; i++) {
  myArray[i] = double(myArray[i])
}

// myArray: [4, 6, 8]

This still works fine, but it has some issues. We have to introduce a variable i which only exists because we need a counter for the for loop, and if we make a mistake in the loop declaration (let i = 0; i < myArray.length; i++) we'll get the wrong answer or errors.

It would be cleaner if, instead of typing out our loop, manually accessing each element one by one and running our double function on it, we could simply say, "take this array, and run double on each element". This is what map lets us do.

Here's our previous example, with the loop replaced with map:

const double = num => num * 2

let myArray = [2, 3, 4]

myArray = myArray.map(double)

// myArray: [4, 6, 8]

That's it! Much cleaner, and no loop constructs to introduce errors. We just call map on our array and pass in the function we want it to run on each element, and we get back a new array with the results.

Note that the original array is not changed by map, it just returns a new array which we assign back to myArray. We could just as easily assign the result to a new variable, and myArray would not change:

const double = num => num * 2

const myArray = [2, 3, 4]

const myDoubledArray = myArray.map(double)

// myArray: [2, 3, 4]
// myDoubledArray: [4, 6, 8]

map does not change myArray, so the result of map must always be assigned to a variable or used immediately!

Now that we've seen how map works, let's look at some different ways to use it. Our double function takes a single value as an argument and returns a single value; this means that map can work with any function which will take a single value and return a single value - even ones we didn't write ourselves!

What if we wanted the square root of every number in an array? Javascript's Math library has Math.sqrt, which takes a number and returns its square root. Let's use that:

var myArray = [4, 9, 16];

var squareRoots = myArray.map(Math.sqrt);

// myArray: [4, 9, 16]
// squareRoots: [2, 3, 4]

When the String object is used as a function, it converts other values to strings:

const myArray = [-1, 9.3e2, false, NaN]

const stringArray = myArray.map(String)

// myArray: [-1, 9.3e2, false, NaN]
// stringArray: ['-1', '930', 'false', 'NaN']

The key takeaway of functional programming here is the idea of passing functions as arguments. We pass a function to map as an argument, and map applies that function to each element in the array.

This about wraps it up for map, hopefully I've explained how it is used and why it is preferable to explicitly writing loops.

If you found this article helpful, follow me! I'll be adding more articles in this series soon. Liked it? Like it ❤️! Suggestions/improvements? Comment ⬇️! :)

Top comments (5)

Renato Byrro • Oct 14 '19

This is very informative. Having only a superficial understanding of functional, in recent weeks it started to grab more of my attention.

I bet you have a good experience with object-oriented. You mentioned that functional drives more "concise and rubust" code. Are you planning to get deeper into the benefits on a future article? Perhaps with some code examples, pointing out practically how these benefits apply?

Kevin Smith 🏴󠁧󠁢󠁳󠁣󠁴󠁿 • Oct 14 '19

Yes, definitely! What I like about functional programming is that you can take a concept, like map in this article, and start using it today in your object-oriented language, and immediately you can reduce loops to a single map and never have off-by-one errors again. Much of my work is very object-oriented Ruby code, yet I use map constantly and could not tell you the last time I wrote a for loop or saw one in a code review.

The main thing I want to convey in this series is that it's not a choice of object-oriented programming or functional programming. You can mix parts of each to write code which is shorter, easier to read, and less likely to contain bugs, without having to dive right into a Haskell-like language.

Renato Byrro • Oct 14 '19 • Edited

Hum, interesting perspective. That indeed makes a lot of sense!

I see many developers adopting functional with a purist view of it. This word - pure - is even part of the paradigm vocabulary. 😄 So I'm interested in getting deeper into the benefits of an entirely functional system, understanding why folks like it so much. In a practical way. Comparing codes in both ways and having better grasp of why one is better than the other.

But I do like the idea of a mixed approach. We all apply it to some extent, actually, without thinking conceptually as functional.

Looking forward to your next articles! 👏