Ayush Hooda
29 Aug 2018
•
4 min read
It’s surprisingly hard to find a consistent definition of functional programming. But I think you can define FP with just two statements:
Hence, Functional programming is a way of writing software applications using only pure functions
and immutable
values.
Now, let us understand the two statements that we stated above.
A pure function can be defined like this:
(a) its input parameters and (b) its internal algorithm, which is unlike an OOP method, which can depend on other fields in the same class as the method.
1
def sum(firstNumber: Int, secondNumber): Int = {
2
firstNumber + secondNumber
3
}
The best FP code is like algebra, and in algebra you never reuse variables. And by avoiding the re-use of variables we can get the benefits like,
You can always rely on a value to replace it with some functionality, for instance, you have val a = f(x)
.
Here you can always use the value a
as a replacement for f(x), as its value can’t be changed, which is not the case with var a = f(x)
. Hence, the algebraic substitutions are possible.
1
val a = f(x)
2
val b = g(a)
3
val c = h(b)
Pure functions are easier to reason about: You know that they can’t do certain things, such as talk to the outside world, have hidden inputs, or modify the hidden state. Because of this, you’re guaranteed that their function signatures tell you two things :
(a) exactly what’s going into each function.
(b) coming out of each function.
1
def doSomething(): Unit { code here ... }
It takes no input parameters and returns nothing, there’s no way to guess from the signature what this method does. In contrast, because pure functions depend only on their input parameters to produce their output, their function signatures are extremely meaningful.
Parallel/concurrent programming is easier: A functional program is ready for concurrency without any further modifications. You never have to worry about deadlocks and race conditions because you don’t need to use locks. No piece of data in a functional program is modified twice by the same thread, let alone by two different threads. That means you can easily add threads without ever giving conventional problems that plague concurrency applications a second thought.
There are a few disadvantages of FP as well but don’t worry, there is a way around to every problem.
Writing pure functions is easy, but combining them into a complete application is where things get hard: All of the functions follow the same pattern:
Gluing pure functions together to create a complete FP application is one of the biggest stumbling blocks you’ll encounter. But there are solutions for this which ultimately is a topic for another day.
Advanced maths terminologies makes FP intimidating: When you first hear terms like combinator, monoid, monad and functor, you feel these terminologies intimidating and that fear factor becomes a barrier to learning FP.
For many people, recursion doesn’t feel natural: For many programmers coming from OOPs paradigm, recursion is a familiar thing but quite often that familiarity level goes begging initially. Due to immutable values, the only way to loop over elements is to use recursion. But once comfortable, it is much more interesting to write codes using recursion.
Because you can’t mutate existing data, you instead use a pattern that I call,“Update as you copy”: It is quite easy to mutate existing data in Non-FP but in FP what you do is :
(a) Copy an existing object to a new object, and then as a copy of the data is flowing from the old object to the new object.
(b) Update any fields you want to change by providing new values for those fields.
Pure functions and I/O don’t really mix.
Using only immutable values and recursion can lead to performance problems, including RAM use and speed: But this can be reduced to a great extent by the use of tail recursion.
FP paradigm is not a replacement of OOP
, but definitely worth learning as it provides an amazing bunch of features as we have discussed above. It is quite hard to decide the side to choose in the battle between FP and OOP, but we can surely say that FP certainly holds the upper hand when it comes to concurrency/parallelism, lots of maths, etc.
I hope now you have a fair idea about FP and quite ready to explore out the FP paradigm.
Learning FP in Scala By Alvin Alexander
Ayush Hooda
See other articles by Ayush
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!