In the last few years, we have seen lots of buzz around functional programming.
There is a new post every day, each reminding us of the same old stuff, functions, purity, no side effects, referential transparency...
By now I hope that everyone with at least a little experience in the business knows the basics of functional programming.
So where is the magic?
Functional programming is more than a few snippets of code, like every other paradigm it is based on concepts, and usually, mastering the concepts gives us transferable skills, and that's what we should be aiming for.
So, instead of showing you how you can use map, filter or reduce to achieve something, I'll explain to you why.
Functional programming has a few unique concepts that we all know, like the ones stated above (functions, purity, no side effects, referential transparency).
Why use functional programming?
Short answer, multi-threading.
Our computers have become very fast in the last few years and we cannot increase their speed a lot. This gives us one answer, increase the cores so we can have more working force.
How does functional programming solve this?
It doesn't, it helps the programmer deal with this, because if we had a functional project running on 1 thread it would be the same as running on 10, remember no side effects, referential transparency, so it's safe.
On the other hand, the majority of the codebases have a lot of side effects which causes programmers a lot of trouble to use multi-threading.
How do we work with a world of pure programming?
We don't.
We need I/O and we need to have different states.
If we have none of that, then we get a heating machine instead of a computer.
The question instead should be how do we approach I/O and state?
Regarding I/O we must encapsulate it in functions with good names that explicitly shows us that we are dealing with impurity.
Regarding state, all of us should be using event sourcing so we never lose data and always can retrieve a state at any point in time.
Bonus
Our brain processes everything sequentially making functional programming and declarative syntax anti-natural.
We must approach declarative syntax by shifting our mindset to one where we try to understand how do we accomplish our goals.
Example: map transforms a sequence.
In imperative syntax, we should see a for loop iterating and transforming the sequence.
In declarative syntax, we have a map, a function we know will transform a sequence, so we give it a sequence and a function that tells it how to transform each element.
Conclusion
Functional programming is a lot more than most of the posts about it, I am still and will always be learning it.
But remember that the best learning approach is by investing in transferrable skills instead of a language or framework.
Top comments (0)