Skip to content
Home » Functional Programming – 3 Fundamentals That Will Make Your Code Safer

Functional Programming – 3 Fundamentals That Will Make Your Code Safer

Functional programming is sometimes called an idea, a process, a style, some kind of boundary, and a way of thinking. Each of these terms is accurate. But technically it is a paradigm. That is a set of concepts of theory and various principles that make up a field. In this case, the field is a given programming style. There are languages ​​like Haskell, the whole idea of ​​functional programming. There are also hybrid languages ​​and languages ​​that introduce only parts of a given paradigm.

Definition:

In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values ​​to other values, rather than a sequence of imperative statements which update the running state of the program.

Now something more human-like: As the name suggests functional programming is a paradigm in which everything relies on functions. Practically we treat functions as wrappers of almost everything we do. We change the state of our app by functions. We combine functions together to make new functions, but about this, I will be writing more in the future. Getting back to the basics:

Pure functions – functional programming building block

Basically, these are functions that for the same arguments return the same results without touching anything outside.

The definition of a pure function is based on the so-called lambda calculus. So quite a complicated mathematical calculus in which in my opinion it makes no sense to delve deeper.
What to remember is that such a function is very similar to a function we know from mathematics. For example, a linear for which we have some x for each y. Likewise, in a pure function for each argument, we will always have the same result. It is professionally called that it should be deterministic.

Side effectless

As already mentioned, the pure function should not affect anything beyond its scope. Technically should not change the outer state and have no side-effects. Ok, but what those side effects are?
Example side-effects:

  1. Mutating input
  2. console.log
  3. HTTP calls (AJAX/fetch)
  4. Changing the file or filesystem
  5. Querying the DOM
  6. Reaching database
  7. Printing something
  8. etc..

Ok then, how can I write a program without side-effects? You cant!

Nowadays in many cases, it is impossible to write functional apps without mentioned above steps. The idea is just to avoid them, not to do them at all. It is commonly said that the best it would be to have 80% of code written functionally and 20% not. But these are only approximate foggy estimations for giving you an overview. Another thing is the way we handle side effects but about this further. By writing side-effectless pure functions we eliminate the risk of breaking something outside totally.

State immutability

The third foundation of functional programming is that we cannot change the state itself. Obviously, modern applications depend heavily on state mutation as well. In FP we just do that by providing a new version of the state, instead of changing the old one. It makes changes of the app’s behavior much more predictable.


So pure function it is one that for every the same argument always returns the same results. Doesn’t mutate the outer state and does not cause side effects by itself. These 3 features make our code very predictable and easy to debug and not breaking anything.

// pure function example
const x = 1;

const add = (y) => y + x;


//impure function example
let a = 1;

const add2 = (b) => b + a;

As we can see in the above example. Which isn’t the best piece of functional programming BTW. But the idea is to show you that sometimes it isn’t so obvious which function is pure. In the example what makes function pure is using const instead of let. const by default in terms of primitive values, which we are using here prevents from mutability.

This function is pure. We are not changing anything outside. We don’t mutate state. For every the same set of arguments, the same results will be produced. One of the problems with this example is having one of the variables outside of function scope.

In this situation imagine we have a class. There are lots of methods and x or a is defined somewhere on the top of the class. Whenever you will be reading add function (this example is a bit trivial) but some other function. Then you will have to go to the declaration of x / a to check what actually our function will return.

const add3 = (x, y) => x + y;

// we can also ad default parameters for safety
const add4 = (x=0, y=0) => x + y;

Remember in FP you should use constructs that prevent mutating state, or provide that immutability by yourself. Such a constructs for example in JS are array functions like reduce, map etc. About immutability in JS I will write more in the future.

Summary

Functional programming is a paradigm in which function takes the lead. Everything that we built, we do it by using pure functions. Which are functions that for every set of arguments, when called return the same results every time, without causing side-effects and mutating state. About how w to meet the requirements of functional programming you will learn in the following articles. In which I will be writing about techniques of writing pure functions, avoiding side-effects, and not mutating state. Code written functionally is very predictable, flexible, readable, scalable, and easy to test.

By following this blog you will learn about higher order functions, partial application, currying, composing, and other advanced FP patterns. For now, if you’d like you can see a brief introduction on my Instagram.
However, if you are just starting your adventure with programming, here you can find out how it works in practice.


Cheers!

Website | + posts

Senior Software Engineer with over 7 years of experience and entrepreneurial background. Most often, apart from delivering good quality code on time, responsible for introducing good practices, teaching programmers and building team bonds andestablishing communication on the line of development-management. Privately Kākāpō and Wombat enthusiast, traveler and retired acrobat.