Why so much love for functional programming?

Here I was, learning Javascript and I came across this definition on MDN -

JavaScript is a lightweight, interpreted, object-oriented language with first-class functions.

Here I am not going to get into the topic of why the creator decided to give JS functional features, instead, I am going to try, to make sense of how functional features like First-Class functions and Higher-Order functions make our life easier while programming in Javascript.

First, let's start with a brief definition of these terms mentioned above because I myself confused these terms with one another.

First-Class Functions: When functions are treated as variables. On top of that, if the function can be passed around as argument to other functions, also if it can be returned by another function and at last if the function can be assigned as a value to another variable. Then we can say that it is a First-Class Function.

Higher-Order Function: Function that takes another function as an argument or returns a function, as a result, are called Higher-Order Functions.

By getting definitions out of the way let's jump into seeing some examples because that's where the fun begins.

Don't Repeat Yourself(DRY)

Suppose your boss comes and asks you to create a function that returns the square of the number 10. (It doesn't happen in real life though :))

I would do something like this:

const = tenSquared => 10*10

But after 5 mins, boss comes again and asks you to create a function that returns the square of the number 9.

I would again do something like this:

const = nineSquared => 9*9

But there is a problem with this code , we are breaking a fundamental principle of programming i.e. DRY (Don’t Repeat Yourself). So to fix this , we can make our code reusable so that our boss can get square of any number he wants. To achieve that we can generalize our function to something like this:

const numberSquared = number => {
 return number*number;
}

Now we don't have that problem of writing the same function code again and again. "Parameters" mean that we don’t need to decide what data to run our functionality on until we run the function. Higher-order functions follow this same principle.

Now let's take a little complex example, suppose again your boss comes and this time he wants you to write a function that takes an array of numbers as input and returns a new array where every input item is multiplied by 11.

multiby11([3,4,5]) // should return [33,44,55]

Give it a try.

I would do something like this:

const multiby11 = arr =>  {
 const output = [];
 for (let i = 0; i < arr.length; i++) {
 output.push(array[i] * 11);
 }
 return output;
 }
const myArray = [1,2,3];
const result = multiby11(myArray)

So far so good, but what if the boss comes again and he wants those same array numbers to be divided by 19. Write the same function again? No, because now we know that this would break our DRY principle. We need a way to generalise this function so that we can have whatever functionality we want to run on the array, at time of calling the function multiby11.

This is where First-Class functions come to our rescue. Let's look at our new code:

const multiByWhatever = (array, instructions) =>  {
 const output = [];
 for (let i = 0; i < array.length; i++) {
 output.push(instructions(array[i]));
 }
 return output;
}
const divideBy19 = input => input / 19
const result = multiByWhatever([57, 38, 95], divideBy19)

So, simply put , what our function is telling us that I am going to create a new Array , loop over the array you have given me , and add to that new Array, for every item that you gave me, your array item is processed by some function that you also give me. So basically we have the full control over our output. And also, you just implemented your own custom map() function.

This was made possible because, in Javascript, functions are first-class objects. They can co-exist with and can be treated like any other javascript object.

Declarative Programming : This is the new buzz word in town , with the introduction of react. And it confused me for a little while but basically in my limited understanding I describe declarative programming as a lazy way of doing things.

Ok , let me explain. In the above example, we implemented the map functionality using for loop and what not. But we don't want to do it over and over again , that's why wrapping the code in a function. The same thing follows for utility libraries like lodash and underscore, someone implemented the underline functionality of the all the functions defined in those libraries but we just get the higher level abstraction of the code written in plain english so that anyone can use it , even if he/she doesn't know how to implement a for-loop in javascript but he will know to loop over any array with forEach, which is a declarative way of doing things but under the hood it it still using that for-loop.

But it's not to say that we should do everything by your own. Infact , abstraction is a feature not a bug. Even in plain HTML and CSS we are using abstraction , giving an item a property of flex-wrap makes it responsive on a smaller devices. It seems like magic but actually it's not. The browser does all the work of running layout algorithms in the background and makes our element responsive. Do we need to know how those layout algorithms work? Probably not, if you are starting out with CSS. But in future if want to make your own browser then it is good to know these things.

Same concept follows for javascript libraries like React , Under the hood, it's mostly plain vanilla js, but for the user, it provides syntactic sugar to make our code readable and easy to maintain.

There's lot more to understand how react works behind the scene which I am learning in my web dev journey and will try to explain those concepts in my future blogs.