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.