Introduction

The programming scientific community works incessantly to break new grounds in inventing languages, frameworks, paradigms, etc. As a consequence of that priceless indefatigable work, we have a new programming paradigm that is not brand new inherently to the research/academic community but finding mainstream relevance nowadays. Various popular languages have adopted the lambda calculus bolstered functional programming ideas. Languages like C#, Java, Haskell, F#, Scala, Clojure, Python, etc. to mention few have been aggressively seizing the paradigm into the gamut of existing features. (note some languages are hybrid and others are pure). I hope to release some specialized posts concerning this concept and bridge the gap of understanding.

Why FP? Or Contemporary Relevance of FP.

Where did it all start? I believe to the limits of my knowledge; FP has been there for quite a while but why is this sudden popularity. Multithreading with multiple cores is omnipresent in recent times. It’s a well-known fact that imperative programming ( akin to procedural code) on multicore with numerous thread running on the same instruction set/function results in data contention. This is where thread-safe code is a champion in the OOPS world. But thread-safe code comes with a cost of slow performance just to avoid resource contention. Now you see, I have abstracted my argument of why OOPS is on the verge of irrelevance in the modern hardware world.

Now here comes our frontrunner, FP, which pushes itself ahead of OOPS in this area of data contention/thread safe, by leaning towards reusable functions that are Pure and handle Immutable data which are well suited for parallel threads. Why? Read further.

Pure Function

Absence of side effects.

A Pure function is just like any regular function but with strict constraints.

·       Global variables (or any variables that persist outside of the scope of the function) cannot be accessed inside the pure function.
·       Such variables cannot be read from, either, unless they are invariant or immutable. (we will deal with immutability shortly.)
·       Pure function can only call other pure functions (this puts a limitation in hybrid languages).
·       Parameters to a pure function can be mutable, but calls cannot be cached or executed asynchronously if the arguments contain any references to mutable data.
·       A pure function can throw an exception.
·       Absence of side effect- ‘a side effect here means any application state change that is observable outside the called function other than its return value’.
·       Functional Determinism or Purity- Pure function behavior must depend only on the arguments provided to the method. The function must return the same answer every time it is invoked on equivalent arguments. Typically, a regular function calls output is determined by various extraneous parameters. But pure function exhibit determinism in the form of functional purity.

Immutability

Perspectives from OOPS world goes like this- every user-defined object you propagate through the system is passed by reference unless otherwise you explicitly pass by value. This creates an insecure ecosystem and hence corruption in data purity, despite scoping, data encapsulation, or data hiding. Why? It’s like this, if one (parent function) consumes an unreliable third-party library function call and pass sensitive data structure into that third-party unreliable function and if it tampers or modifies with the sensitive data structure resulting in a data security violation. Now the question that begs here, is there a way to innately build a secure way of data handling as part of language feature rather than the programmer taking the onus?

“Any write operation inside the unreliable function call will create a copy of data structure with new reference and this is also called as copy-on-write (COW). Or it can also be that, a deep copy of data structure that gets passed from parent function into other third-party functions not by programming syntax but by language feature”

What does Pure Function & Immutability solve?

Now, what does pure function & immutability hand in hand solve? Like we talked above, OOPS result in data contention in multithreaded setup, but on the other hand, FP innately doesn’t allow its function to tamper or modify with any resource outside its purview. This way it is scalable and modular.

Conclusion

There are different notions and perspectives towards FP.  A single post is not enough to greedily address all of that. Remember, I grow with these posts like you all do. I am going to post more FP content in the future. The power of FP is in the modularity of reuse and along with the pure functions + immutability.