There exist many tutorials and introductory blogs on Functional Programming (FP from now on).
However, I think too many are theoretical, scary and very time consuming.
If you already are an FP nerd, skip this series of articles. It won’t bring anything new. This series aims at giving a simple and yet clear introduction to functional programming, what it is, what it is not and what benefits you can draw from it.
In this first article, I will share my experience of converting to FP and will try to guide you through the jungle of FP libraries.
Jumping into the FP jungle
Like most programmers around the place, I was an Object-Oriented Programming (OOP) fan. However, it had already dawned upon me that the available JS tools for array and list management were a bit limited. So, I would never fail to import Ramda or Lodash when my code took me to data manipulation. That included using array map, reduce or forEach functions. At some point, a bit curious about all these weird words that you find in the Ramda doc (words like functors, transducers, transformers,…) , I started digging more deeply.
Ramda and the likes
Back then, my perception was that a functional programmer is a person who sticks to his well-known OOP paradigm but writes lots of small functions and makes extensive use of Ramda or the likes when it comes to manipulating data.
The internet is full of blogs and articles that will reinforce that cliché. If you look for “functional programming library javascript” on your favorite search engine, you will find dozens of libraries like Ramda, Rambda, Rambdax, Remeda, Lodash, Bluebird, Curry,… Each of these libraries has its active community that discusses in great details the benefits of extensively using reduce or transduce when it comes to analyzing or managing data. The usual “10 best FP libraries for 2023” websites mainly put the focus on execution speed and function count. The Grail seems to be that new library that does as much as all the previous ones but much faster and with more available functions.
So, can we reduce Functional Programming to an extensive and clever use of the reduce function (accidental pun)?
Monads and monoids
However, if you can spare the time, you might also notice while roaming around on the internet a bunch of other libraries written by seemingly mad scientists who keep throwing Monads and Monoids at you. Examples of such libraries are TS-belt, Folktale, FP-TS, Effect… All these libraries seem very scary at first glance. You will find lots of chitchat on forums discouraging you from looking further in that direction. The main reasons invoked are:
- not very spread in the IT community: other developers will not be able to understand and maintain your code.
- difficult to integrate: FP does not go well with existing frameworks.
- beautiful but too theoretical: coders have to be practical and efficient. It’s enough to put a bit of Ramda here and there in your OOP dev.
It’s easy to let oneself be convinced to look away from monads and monoids. The names are (purposefully?) scary. Most of this stuff is written by mathematicians and academics. Reading articles on these topics is a time-consuming hassle (really is).
So why would you want to go further than Ramda?
Confining oneself to using Ramda now and again amounts to swimming in the baby pool without ever wanting to dive in the large deep ocean.
FP is not about providing utilities for arrays. Ramda definitely was a necessary step in the history of Functional Programming. But, as often in science, it is been absorbed and outperformed by the broader concepts it gave birth to. The map function that we all use with arrays as been theorized and can be in fact applied to many more objects. Nowadays, functional programming is about efficient function composition, data aggregation, asynchronous and synchronous code management, error and resource handling, code reliability and testing… All these topics are very current in modern development. Going into the monadic world is definitely taking a lead in development techniques.
However I think it unnecessary to talk long hours about monads and monoids and the mathematics underpinning then. That would make me very smart but wouldn’t help you much. Instead, I suggest we take a pragmatic example and try to figure out how OOP and FP approaches would differ in that particular case. We can then pragmatically discuss the pros and cons of each solution. That will be the topic of the next article in this series.
Top comments (0)