Functional programming — Why's?
Hello, we are at the beginning of something I think will be the first episode in a series of functional programming content, the content will be highly inspired by a presentation that I give at the company I work for previously and the main objective is to wet the feet of the reader into the functional programming main concepts. But before, I would like to answer some important questions:
Why so much hype?
Functional programming is not a new topic, its concepts have been around the programming world since the 1950s with Alonzo Church and its lambda calculus, but what makes a paradigm from the fifties create so much hype nowadays? Well to me, I consider that all this hype is because of three main reasons:
— Compilers
Compilers are probably the most advanced area in computer science and brought many evolutions to programming languages design and functional languages because of the characteristics of the paradigm were able to apply and implement these improvements in theirs syntaxes and compilers/interpreters what made functional programming languages more efficient and specific domain problem solvers than ever before.
— Processing power
A new world is opening in modern software development, and it is multicore programming in the last few years, we are seeing a lot of new languages focused on the problem of handling multicore efficiently, safely, and concisely and at the same time allowing our programs to be maintainable and expressive. In the past, this wasn't a problem because processors would double their processing power at every x years time interval so the language I build my system doesn't matter because I will get this program to run twice as fast every x years, but it came to a limit due to the physical resistance of the materials and the only way to make a program run faster now is by using the multiple cores in the processor.
Multicore programming in imperative languages is not an easy task, because I share and modify states I can't just run multiple instances of my program one on each core, and hope it will run safely and concisely, due to sharing states now I have multiple programs trying to access the same points in memory at the same time, and it generates race conditions turning my program insecure and risking compromising the data and/or the execution of the program.
Race conditions are very hard to deal with because in testing environments I will not have multiple instances with multiple users trying to access the same points in memory at the same time, so I cannot detect it in my tests properly and if I cannot test it, certainly race conditions have a tendency to appear in production with real clients doing real and serious operations, and we will not be able to ensure everything will be concise and safe. Race conditions don't are just hard to detect and test, they are also hard to keep tracing and be fault-tolerant against because we will never know when another race condition can happen in the execution of our programs.
Now that we saw the nightmare of race conditions caused by insecure parallelism that shares memory between processes, let's talk about how functional languages usually deal with that:
If you don't share or modify your states you can guarantee safety and secure parallelism.
But how do functional languages make sure every process will have the data it is needed to execute the program? By creating immutable copies of the data in memory unique to every process, so I don't have memory sharing in my program anymore and because I don't share memory I don't compromise my system's execution, and we get safe parallelism basically for free in functional languages.
— Memory
To create all these copies and make sure all unnecessary data will be removed from memory, in general, functional languages use more memory than imperative languages and in the past, memory was very expensive and finite, but with the advent of cloud computing we have cheap and accessible memory and if we need some more GB of memory we can just create another instance of our app in the cloud provider next door for a very fair amount of money, with the problem of memory solved now there's nothing on the way to limit functional languages applications in real-world, and it comes in hand to solve that huge tasks of running multicore applications safely.
With these three points aligned, the functional languages got a big hype around them, and they became a hope and a symbol of concise code, expressivity, and execution safety.
Why learn functional programming?
Well functional programming is a very wonderful topic inspired by lambda calculus and mathematics and to me is the essence of the beginning of the definitions of computation and not just about being a very fascinating topic, more and more functional languages are being created every year usually as a lisp or ml dialect and languages of the past that adapted very well to our current necessities like Erlang, Haskell are finally getting their place in the sun and of course, imperative languages(java, python, JS) are adding more and more functional features to their syntaxes and Softwares too, excel recently added lambda functions to help in the creation of sheets.
Now that I answered some crucial questions about how's and why's functional programming is so in vogue right now, in the next chapters I hope to go through some important concepts in functional programming, so see you in the next article.