What is Functional Programming?

If you go back in computer history, you'll find that the second–oldest programming language still in use, LISP, has its bases in Functional Programming. Since then there have been many more functional languages, and FP has been applied more widely. But even so, if you ask around what FP is, you'll probably get two widely dissimilar answers.

Depending on whom you ask, you'll either learn that it's a modern, advanced, enlightened approach to programming that leaves every other paradigm behind, or you'll be told that it's mainly a theoretical thing, with more complications than benefits, practically impossible to implement in the real world. And, as usual, the real answer is not in the extremes, but somewhere within.

For Trivia buffs, the oldest language still in use is FORTRAN, which appeared in 1957, a year before LISP. Quite shortly after LISP came another long–lived language: COBOL, for business–oriented programming.

Theory versus practice

In this book, we won't be going about FP in a theoretical way: our point is, rather, to show how some of its techniques and tenets can be successfully applied for common, everyday JavaScript programming. But, and this is important, we won't be going about this in a dogmatic fashion, but rather in a very practical way. We won't dismiss useful JS constructs, only because they don't happen to fulfill the academic expectations of FP. We won't avoid practical JS features just to fit the FP paradigm. In fact, we could almost say we'll be doing SFP—Sorta Functional Programming because our code will be a mixture of FP features and more classical imperative and Object Oriented Programming (OOP).

(This doesn't mean that we'll be leaving all the theory by the side. We'll be picky, and just touch the main theoretical points, give some vocabulary and definitions, and explain core FP concepts... but we'll always be keeping in sight the idea of helping to produce actual, useful, JS code, and not to try to achieve some mystical, dogmatic FP criteria.)

OOP has been a way to solve the inherent complexity of writing large programs and systems, and developing clean, extensible, scalable application architectures. However, because of the scale of today's web applications, the complexity of all codebases is continuously growing. Also, the newer features of JS make it possible to develop applications that wouldn't even have been possible just a few years ago; think of mobile (hybrid) apps done with Ionic, Apache Cordova, or React Native, or desktop apps done with Electron or NW.js, for example. JS has also migrated to the backend with Node.js, so today the scope of usage for the language has grown in a serious way, and dealing with all the added complexity taxes all designs.

A different way of thinking

FP implies a different way of writing programs, which can sometimes be difficult to learn. In most languages, programming is done in imperative fashion: a program is a sequence of statements, executed in a prescribed fashion, and the desired result is achieved by creating objects and doing manipulations on them, which usually modify the objects themselves. FP is based on producing the desired result by evaluating expressions, built out of functions composed together. In FP, it's usual to pass functions around (as parameters to other functions, or returned as the result of some calculation), to not use loops (opting for recursion instead), and to skip side effects (such as modifying objects or global variables).

Another way of saying this, is that FP focuses on what should be done, rather than on how. Instead of worrying about loops or arrays, you work at a higher level, considering what you need to be done. After getting accustomed to this style, you'll find that your code becomes simpler, shorter, more elegant, and can be easily tested and debugged. However, don't fall into the trap of considering FP as a goal! Think of FP only as a means towards an end, as with all software tools. Functional code isn't good just for being functional... and writing bad code is just as possible with FP as with any other techniques!

What Functional Programming is not

Since we have been saying some things about what FP is, let's also clear some common misconceptions, and consider some things that FP is not:

• FP isn't just an academic ivory tower thing: It is true that the lambda calculus upon which it is based, was developed by Alonzo Church in 1936, as a tool in order to prove an important result in theoretical computer science. (This work preceded modern computer languages by more than 20 years!). However, FP languages are being used today for all kinds of systems.

• FP isn't the opposite of object–oriented programming (OOP): Also, it isn't either a case of choosing declarative or imperative ways of programming. You can mix and match as it best suits you, and we'll be doing that sort of thing in this book, bringing together the best of all worlds. 

• FP isn't overly complex to learn: Some of the FP languages are rather different from JS, but the differences are mostly syntactic. Once you learn the basic concepts, you'll see you can get the same results in JS as with FP languages.

It may also be relevant to mention that several modern frameworks, such as the React+Redux combination, include FP ideas. For example, in React it's said that the view (whatever the user gets to see at a given moment) is a function of the current state. You use a function to compute what HTML and CSS must be produced at each moment, thinking in black box fashion.

Similarly, in Redux you get the concept of actions that are processed by reducers. An action provides some data, and a reducer is a function that produces the new state for the application in a functional way out of the current state and the provided data. 

So, both because of theoretical advantages (we'll be getting to those in the following section) and of practical ones (such as getting to use the latest frameworks and libraries) it makes sense to consider FP coding; let's get on with it.