The C-Files: Functional Programming

Why should you use it?

Since I took up javascript, I’ve seen a lot of content put out by developers that argue for or against the use of certain programming paradigms over others. When coming across all this jargon-laden stuff, in my naivety I was asking

“What is the point really? The code you write is a solution to a problem and it shouldn’t matter how you get there.”

Before learning about other styles, I really only practiced imperative programming. Imperative programming feels like a more thorough style of programming that, while great for beginners who are getting a feel for the syntax and methods of a language, is not great for a lot of other reasons. For one, and this is more nitpicky than anything, programming in this style usually lends more lines of code. This is because a solution in this style often has the look of a something like a mathematical proof.

Take a look at this for example

In this hilariously bad example of code, you can see that even without inline comments, each line of that function is descriptive of the operation that is going to occur, which is that a number will be divided by another number. You can see what each parameter is clearly and you can see how it is used step by step.

Each visible line of code is like a step detailing a part of the solution. This can actually be very useful for people who are not familiar with your code, since they can see what you are trying to do at each step. The real issue that some developers may have with the imperative style, is that it makes modifications to a program’s state. But what is a program’s state?

A simple definition of state is basically all of the values stored as variables for a given program. State is something that can change. If an app relies on storing data in variables, and allows users to input data that changes the values, the program’s state is changing. In the above example, I declared two variables in a global scope, and another inside of a the function body (local scope). In my example these three variables and their values comprise this program’s (albeit small) state.

You might be saying “Yeah…duh. That’s why most programs work, values are stored and people can modify those values and its no big deal usually.”

Well, it’s less the fact that imperative style relies on storing the data as state; this is not an issue of memory usage. But more an issue, on what changes of state DOES to the inner workings of a program.

In the above example, before I run the program, the number variable is set to equal zero. After running the divide function, it returns the number five but only after having set the variable number to the same.

Imperative programming can involve a reliance on storing data in variables in global or local scope. Globally scoped data in particular can be easily changed because all the functions you write can access and potentially modify that data, like in the example. If your program relies heavily on changing variables in a global context, you are going to modifying state to produce something computer scientists call side-effects, (basically changes in state). This can cause a lot of issues. For one, if your program design involves many functions sequentially passing around values stored in a higher scope, you are going to be mutating this data quite a bit. You may need variables to have specific values on start. When you run the program again, the data will be different than what you wanted for at start. Also, if your program is very complex, and you notice changes in state that you did not want, you are going to have a more difficult time debugging where these variables are changing and why a particular change is occurring.

This is where functional programming comes back into the picture. Functional programming is about avoiding these side-effects. If you need to have any data that multiple functions need to use in your program, you want to avoid mutating that data. This is where javascript methods like

Object.assign() or .map() built into recent editions of javascript, become very useful in the functional programming paradigm. If you want to make changes to a data structure in your program, you don’t want to mutate it directly. You want to encapsulate that data in a function and make modifications to it within the body of the function, then return that data in what looks to be a modified form. The original data structure will be intact, no changes to it.

This will make designing a program interface easier because you do not have to worry about how data is being modified and reset depending on what functions are being invoked. At the end of the day, your program will probably still have many changes in state, it’s just that a main goal of functional programming is to reduce how many of those changes occur.

You’re probably asking “Ok so how does one actually do functional programming?”

There are a few design patterns that you can follow that will conform to the standard for this paradigm. One big ones is to write Pure Functions, functions that do not cause changes in state and just return a value, the operations for doing such being contained in the function body. This is very common and you probably do this all the time. We can reuse the example above to write a pure function

As you can see, our original variables haven’t changed here despite being used as arguments. We are returning a value by using those variables but the computation is not mutating them.

Another way you can implement the functional programming paradigm is through the use of Modules. These are kind of similar to classes in that they comprise variables and methods that are encapsulated together inside of an object.

There are many different design patterns just for modules alone in JavaScript but the pattern above will effectively shield the number variable from being called on and accessed from outside the IIFE that it is housed in. The only way that can be accessed is by using a method inside a return block, and from there we can choose to do with it what we will.

There are many ways to implement a functional programming paradigm in your applications, so you can feel free to explore design patterns or libraries like Immutable.js or ramda.js along with a plethora of others which cater to developers in this paradigm. Happy coding!