Functional programming patterns are exploding their way into common consciousness as more developers talk about them. However, the ideas behind them are not exactly new.
They’re simply an alternative way to instruct our code to be evaluated.
First, Let’s Get Back to the Basics
Functional programming (FP) is a type of paradigm or pattern in computer science, which runs on the idea that what you put in will always produce the same outcome, regardless of order. Everything is done with the help of functions in FP and the basic building blocks are functions only.
Programming languages supporting purely functional programming:
Some of the programming languages supporting functional programming as well as other programming paradigms:
For example, regardless of how you add or subtract the following numbers, the result will always remain the same.
3 + 8 - 5 = 6
8 + 3 - 5 = 6
8 - 5 + 3 = 6
Functional programming is like making a loaf of ciabatta — it doesn’t matter what order you put the ingredients in (flour, water, yeast, and salt). As long as they’re all there, in the right quantities and mixed together, you can’t really mess it up. Trust me, I’ve tried.
Functional patterns and ciabatta loaves are two of the few fail-safe things in life!
const cat = Cat();const makeCatJump = jump(cat);
What’s happened here is that the Cat() function is assigned to the variable cat and the generated output is treated like a value, which is then passed into the function jump().
It may sound complicated but it’s actually more like substitution in mathematics.
Here’s a diagram to help make it easier to mentally digest.
So where exactly would you use this? Anything that requires functions as a substitution stand-in like async flow controls with callback functions. It’ll save you from writing how to deal with the async results over and over again, in addition to making your code much more readable.
No Mutants Here
Well, that’s a bit of an exaggeration. When it comes to functional patterns, mutable objects are never part of the equation. This is because data becomes lossy.
What does lossy mean?
Lossy is a concept in which data is discarded and has the potential to change — in other words, it is mutable. Immutability creates a certain permanence when traveling through the functional pattern. If we look at the mathematical example given earlier, we don’t expect the 8 to suddenly morph into a different number. The same concept is applied to functional programming.
It’s important to note that using const to create immutability is a bit of a misunderstanding. While you can’t change the assigned value to a const, you can still add to it, which means that const is actually mutable.
True immutability means that you can’t change or make additions to it at all, otherwise the value becomes mutable.
However, this method only works on the surface and applies to the first level of objects only.
For example, the following is a mutable object:
What’s the Big Deal with Immutability?
At some point, your data is going to need to change. Immutability isn’t exactly about the values assigned but rather the shape of the thing you are working with.
In the catDetails objects above, the first example is immutable because freeze() prevents it from changing in shape through the addition of weight. In the second example, the shape is mutated by the addition of catDetails.greeting.night
The big deal with immutability and its hard rule in functional patterns is that it ensures a level of predictability. Imagine you’re receiving a cart object but find yourself in a bit of a pickle because, somewhere along the lines, your cart items’ expected data shape has changed.
When your expected values are immutability, it also allows you to create references and value equality with hidden side effects. Testing becomes easier because you know exactly what to expect for inputs and outputs. With functional patterns, there are no contingencies or ambiguity to deal with.
Understanding how functional patterns operate can also de-codify your code by making it more straightforward. The long-term stability of your code is not resting against the potential of change. Rather, it just does the job it was designed to do — giving your code a level of vaccination against technical debt.
Thank you for reading.
JT1 - IT Recruitment Agency
Phone: +8428 6675 6685