While some of us have been introduced to functional programming at college, some may have heard a bit about it and others may have used it with the implementations offered by some languages in the market. To them, the essence of the concept of functional programming may be lost. Many times, the word paradigm is omitted, which adds to this lack of awareness. My goal is to clarify what the functional programming paradigm is and answer a series of implicit questions: What’s its purpose? Is it just a trend? Is it something purely theoretical?
Science considers that a paradigm is a model for carrying out research and scientific experiments, and believes that this model can be replicated. Besides the fact that it’s an experimental model, a paradigm involves the way the agents in the scientific field learn, think about and make science.
Going a little farther, the paradigm tries to explain and accommodate the behavior of certain things in the real world, from a virtually uniform perspective. Along the life cycle of the current paradigm, that is, the one which governs the way we conceive the world, problems will arise that may seem unsolvable. When the paradigm can no longer overcome these problems, it will enter a period of crisis that will end when a new paradigm gains supporters and brings that one down completely.
What does all this have to do with programming?
I’m getting there.
- The concept of paradigm also applies to the way programmers learn, think about and make software. It determines the conceptual tools that they can use and the valid ways to combine them.
- A programming paradigm tries to solve problems from a virtually uniform perspective.
- When the programming paradigm cannot give answers to the new challenges of the world, and new paradigms that have less legitimacy but can solve those new problems emerge, a transition period begins.
The Functional Programming Paradigm
What’s the place of functional programming considering the definition of scientific paradigm?
- The Imperative Paradigm
Initially, the prototypical paradigm was the imperative paradigm. In general, the process was as follows: a defined global state was made to go through a sequence of transformational steps until a final result was obtained, the product of those transformations. In this paradigm, each step builds on the previous one and, therefore, cannot be reused; it is meaningful only in the context of the sequence of steps. In addition, to understand the purpose of each step, it is necessary to grasp how the entire flow works, due to their interdependence. As a result, we get a solution to one specific problem only.
- The Object-Oriented Paradigm
Under this paradigm, the sequence of the previous case is divided into modules. The encapsulation results in breaking up the global state into smaller pieces that are hidden in data structures named classes. But the essential problem isn’t addressed at the paradigm level, instead, the implementation remains hidden in the objects, which are combined to work together. It’s true that this enables a higher level of abstraction, but with the downside that two things that shouldn’t be left out of sight are hidden in the objects: state mutability and data sharing. These two don’t get along well with concurrency problems and parallelization, which can arise at some point.
- The Functional Programming Paradigm
Finally, we come to the functional programming paradigm, in which mutability is removed instead of the global state. Unlike the previous ones, this paradigm considers function as its fundamental unit. The idea is to develop pure functions in a mathematical way. It’s a systematic (and proven) way of developing smaller parts of code and then enlarging them. In this way, there is a wide variety of mathematical models at disposal.
Advantages of the Functional Programming Paradigm
This paradigm offers a method to elaborate theories about domain problems, and it allows us to develop code that is more resistant to change than previous paradigms.
Conceiving problems in this way offers a series of advantages:
- It facilitates unit tests.
- It reduces bugs created by mutability.
- It separates the business logic from the control of the application.
- It is easier to prove its validity, thanks to its mathematical basis.
What a Programming Paradigm is NOT
How many times do we hear people claiming they “use Scrum” simply because they meet once a day and comment on the things each one is doing? If we dig a little deeper, we find that type of meetings last no more than forty minutes, there is no moderator, and participants tell with a great level of detail what they are doing at the moment. That’s not Scrum. Why? Scrum as conceptual framework is a series of rules, laws or guidelines, and when they aren’t followed, it means that the Scrum way of thinking isn’t maintained.
That doesn’t discredit the people who choose to work in that way, it simply makes the statement that they are using that paradigm invalid, since the paradigm is the way a task is carried out.
The same happens when some languages implement functions that belong to the functional paradigm. Those who aren’t familiar with the paradigm nevertheless claim that they follow it simply because they use a map or a function of the sort. In order to really understand the way this paradigm (as well as any other) works, we need to know its rules and motivations, which requires further discussion. It’s not enough to use the implementations of the language nor leverage some aspects of the paradigm to claim that one is following it.
How to Think About Programming
It’s essential to consider programming from the point of view of the paradigm of choice, which will enable cohesion when solving problems and make it easier to reuse code in the long run. That way of thinking requires us to know the tools and rules suggested by the paradigm we choose.
It’s worth clarifying that on no account do we intend to discredit other paradigms in force. In fact, the object-oriented paradigm has proven to be very useful. The important thing is to know what the aspects of the current paradigms are, so as to make the right choice when designing a solution. Perhaps, due to all its advantages, the functional paradigm will eventually reposition itself, but the important thing is to keep a critical mind and explore the tools that each paradigm has to offer, in order to decide which gives the best framework to think and solve.
Lastly, remember that languages provide implementations for the paradigms’ conceptual tools. While some languages focus only on the proposals of one paradigm, there are others that allow a combination of several ones. However, the paradigm refers, above all, to the mental process used to develop an application, rather than the language.
The main advantage of this paradigm is the possibility to reuse code, reduce the impact of changes and reduce the number of possible bugs. Even when some may conceive programming as an art or a form of expression, the only thing that matters at the end is being able to solve a problem in the shortest period of time possible.