Demystifying Functional Programming (Part 2) — The need for immutability

Welcome back, For those who have not gone through the previous blog of this series, I would recommend to go through the Part 1 (5 min read) for a better understanding!

What is Immutability and Mutability?

Immutable objects are objects whose state cannot be changed after declaration where as mutable objects are variables, whose state can be changed over the whole execution of the program.

In java you can treat final as immutable where as in scala all the fields declared as ‘val’ are immutable and ‘var’ are mutable!

Strings are also immutable in Java

Some of you might think that we can change the value of string over the period of time or perform ‘concatenation’ operation on it. Well definitely you can perform that, but when you do, another object of string is created without modifying the previous object holding that value in the memory of heap.

Let’s not go deep into language specific things here!

Why Immutability?

In a plain scenario where you want fast processing taking advantage of your multi core CPU, you need to parallelise your code and run it in a distributed fashion. Having immutable fields means you need not worry about parallel thread interacting with each other and changing the state of other fields. This makes effortless parallelism without fearing any thread safety issues.

Writing mutable parallel code is hard and very error prone. Immutable functional programming is almost the only way we know how to do this safely and easily.

Make your variables immutable, unless there’s a good reason not to.

There might be many question in your mind that not everywhere we can use the immutability concept like in loops or assigning a value to a field depending upon the conditional expressions.

I will answer this in some time, before let’s know one thing that In a functional programming language “Everything ‘evaluates’ to a value”. What that means is that even an if else statement would be returning an object to you!

In the first picture, we are using a mutable fields ‘flag’, which we could have easily avoided using the concept that in functional programming everything evaluates to a value. So the if else condition return a true/false expression which is stored in the immutable field ‘flag’ in the 2nd image.

Give up on your most favourite variable ‘i’ before it’s late! Another example on how to avoid for loops, if you are using stream function in java 8 you would understand the below codes, anyway I would try to explain that! So we have a list and we want to increment it’s values by 2 (add 2 to every value)

The first image is self explanatory and the basic way of approaching things, coming to the 2nd code snippet, we have used a ‘map’ function which is nothing but a transformation function in scala. Putting a map on a List takes us inside the list giving access to every value which is represented here as ‘ _ ‘ (underscore). So, underscore is our Integer values that the list is having one at a time. To solve our problem we just do a ( _ + 2) which gives us the required output creating a newList!

You could use ‘map’ in Java 8 as well but you need to do an extra step of converting the list into streams, so the immutable code in java would look like-

final List newList= list.stream().map(value -> value + 2).collect(Collectors.toList());

Last example — Sum numbers from 1 to 10-

val sum10 = (1 until 10).foldLeft(0){
  case (sum,curr) => sum + curr
}

Here (1 until 10) will give you a range. FoldLeft is a traversable function provided to take values from left to right with a default parameter ( 0 i.e sum here). As seen in the above code snippet we omitted the use of declaring a mutable field SUM.

Conclusion:

If you want to write parallel code making use of most of the processing power and want a thread safe way — immutability is the answer!

If you have question regarding how to convert a mutable scenario into an immutable one, you can reach me out on my LinkedIn handle! :)