The first step toward understanding the ideas of functional programming is the most important one, and sometimes the hardest. But with the right approach, there's no need for it to be difficult.

Why do you need to know about functional programming, what is it for, and what now?

Now that you've learned all this wonderful new material, you might be thinking, "So what now? How do I use this in my everyday code?"

There are several options here. If you can program in a pure functional language such as Elm or Haskell, it will be easy for you to put all these ideas into practice, and such languages make it straightforward to do so.

If, on the other hand, you can only program in an imperative language such as JavaScript (the level all of us should have), you can keep using everything you've already learned, but now with more discipline.

The Capabilities of Multi-Paradigm JavaScript

JavaScript has many features that let you program in a more functional style. You won't get full purity, but you can achieve some immutability with the language itself and even more with libraries.

It won't be perfect, but if you need to use functional capabilities, why not take advantage of some of the language's strengths?

The Principle of Immutability in Functional Programming

So, what is immutability? In ES2015, also known as ES6, a new keyword for declaring variables appeared — const. It means that once a variable has been set, it cannot be reassigned:

const a = 222;
a = 111; // throws a TypeError 

Here a is defined as a constant, and for that reason it cannot be changed after being set. That's why the expression a = 111 throws an error.

The problem with const is that in JavaScript it doesn't go as far with this idea as it should. The following example illustrates its limits:

const a = {
    x: 1,
    y: 2
};
a.x = 2222; // NO EXCEPTION!
a = {}; // but this DOES throw a TypeError

Notice that a.x = 2222 does NOT throw an exception. The only thing that stays immutable with const is the variable a itself. Everything that a defines inside itself can still be changed.

This is a terrible disappointment, because the absence of this shortcoming would have made JavaScript a much better language.

So how can we achieve full immutability in JavaScript?

Unfortunately, this is only possible with the Immutable.js library. It's supposed to give us the proper level of immutability, but unfortunately, using it also makes our code look a lot more like Java than JavaScript.

The Concepts of Currying and Composition and Their Application in FP

Earlier, in one of the previous parts, we learned how to write curried functions. Here's a more complex example on this topic:

const f = a => b => c => d => a + b + c + d;

Notice that we had to write the curried version of the function by hand.

And to call f, we have to write:

console.log(f(1)(2)(3)(4)); // prints 10

But there are enough parentheses here to make a Lisp programmer cry.

There are many libraries that make the task of currying easier. One of my favorites is Ramda.

Using Ramda now lets us write:

const f = R.curry((a, b, c, d) => a + b + c + d);
console.log(f(1, 2, 3, 4)); // prints 10
console.log(f(1, 2)(3, 4)); // also prints 10
console.log(f(1)(2)(3, 4)); // also prints 10

The function definition doesn't look much better, but now we've managed to get rid of the need for all those parentheses. Notice that we can apply as many arguments as we like when calling f: all of them at once, or just a few.

Using Ramda, we can rewrite the mult5AfterAdd10 function from Part 3 and Part 4:

const add = R.curry((x, y) => x + y);
const mult5 = value => value * 5;
const mult5AfterAdd10 = R.compose(mult5, add(10));

This example shows that Ramda has many helper functions for tasks like this, for example R.add and R.multiply, which means less code for us:

const mult5AfterAdd10 = R.compose(R.multiply(5), R.add(10));

The map, filter, and reduce Functions

Ramda also has its own versions of map, filter, and reduce. Even though these functions exist on Array.prototype in native JavaScript, their Ramda versions are curried:

const isOdd = R.flip(R.modulo)(2);
const onlyOdd = R.filter(isOdd);
const isEven = R.complement(isOdd);
const onlyEven = R.filter(isEven);const numbers = [1, 2, 3, 4, 5, 6, 7, 8];
console.log(onlyEven(numbers)); // prints [2, 4, 6, 8]
console.log(onlyOdd(numbers)); // prints [1, 3, 5, 7]

R.modulo takes two parameters. The first is the dividend (the number we're dividing), the second is the divisor (the number we're dividing by).

The isOdd function returns the remainder of division by two. A remainder of zero for an even number returns false, and a remainder of one for an odd number returns true. We flipped (translator's note: flip) the first and second parameters of modulo, so we could set 2 as the divisor.

The isEven function is simply the inverse (translator's note: complement) version of isOdd.

The onlyOdd function is a filtering function with the predicate (a function that returns a boolean value) isOdd. Before it executes, it waits for the last value in the array of numbers passed to it.

The onlyEven function is a filter that uses isEven as its predicate.

When we pass numbers into onlyEven and onlyOdd, isEven and isOdd receive their final arguments and can finally execute, returning the expected numbers.

What Are the Drawbacks of JavaScript?

Despite all the libraries and extended language features JavaScript has gained, it still suffers from the fact that it's an imperative programming language trying to be everything to everyone.

Most frontend developers have gotten stuck in one place, using JavaScript for the browser because for a long time it was the only option. But now many developers are moving away from writing JavaScript code directly.

Instead, they write in other languages and compile, or more precisely transpile, them into JavaScript.

One of the first such languages was CoffeeScript. Now Angular 2 (translator's note: "now" was current for Angular 5) has adopted TypeScript. Babel is a transpiler for JavaScript.

More and more people are turning to this approach in production.

But all these languages started with JavaScript and only made it a little better. Why not go all the way and transpile JavaScript from a pure functional language?

The Elm Programming Language

Throughout this series of articles, we've turned to Elm to better understand functional programming.

But what is Elm? And how do I use it?

Elm is a pure functional language that compiles to JavaScript, so you can use it to build web applications using The Elm Architecture, also known as TEA (this architecture inspired the developers of Redux).

Applications written in Elm do NOT encounter any runtime errors.

Elm is used in production by companies such as NoRedInk, where Evan Czaplicki, the creator of Elm, currently works (he previously worked at Prezi).

Listen to the talk 6 Months of Elm in Production by Richard Feldman, an Elm evangelist at NoRedInk, for more details.

Should I replace all my JavaScript with Elm?

No. You can gradually replace parts of your code. To learn more, check out the article How to Use Elm at Work on the Elm blog.

Why learn Elm?

1. Programming in a pure functional language brings both restriction and freedom at the same time. The restriction lies in limiting your actions (often protecting you from yourself), but at the same time you're freed from bugs and poor architectural decisions, since Elm applications follow The Elm Architecture, a functional-reactive model.
2. Functional programming sharpens your skills as a programmer. All the ideas mentioned above are just the tip of the iceberg. You really should see them applied in practice to appreciate how much smaller your programs become and how much more stable they get.
3. JavaScript was originally written in ten days and then patched over the following two decades to become a somewhat functional, somewhat object-oriented, and fully imperative programming language. Elm was designed drawing on thirty years of experience from the Haskell community, itself built on decades of work in mathematics and computer science. The Elm Architecture (TEA) was planned and refined over many years and is the result of Evan's personal achievement in functional reactive programming. Watch Controlling Time and Space to appreciate the level of thinking behind this architecture.
4. Elm was designed for frontend developers. It aims to make their lives easier. Watch Let's Be Mainstream to better understand this goal.

The Future of Functional Programming

It's impossible to predict exactly what tomorrow will bring, but we can make some educated guesses. Here are a few of mine:

There will be a definitive shift toward languages that compile to JavaScript.

The ideas of functional programming, which have been floating around for forty years, will be rediscovered to solve our pressing problems of software complexity.

The state of hardware, particularly cheap gigabytes of memory and fast processors, will make functional approaches viable.

CPUs won't get any faster, but the number of cores will keep growing.

Managing changing state will be recognized as one of the core challenges of complex systems.

The future belongs to functional programming, so make an effort to study it more deeply and apply it in practice.

Our articles will help you master all this information more easily and quickly, so that you become a more sought-after specialist than those who don't have this knowledge and these skills.

After reading these articles, you should feel more confident in your abilities and in your understanding of FP concepts.