Most of the programs that one develops as a student of computer systems are highly likely to have been designed in an imperative paradigm, since it is one of the most common ways in which it is currently programmed. However, as technological trends evolve, you also have to start contemplating other forms of programming and one of the best options that has emerged in these times is the functional programming that due to its robustness, efficiency and parallelization has become a totally viable paradigm to generate software.
It is hard to realize that in functional programming it is not essential to use variables or cycles. This is because, literally, the functions act in a mathematical sense and do not work like the routines to which we are accustomed. Even getting to have a good performance in functional programming depends on how willing we are to forget the way we program and start accepting new programming schemes.
Among the things most present in functional programming is abstraction due to the way functions are formed. Some things that seem curious are high-level functions, since these functions may contain functions that send more functions and you are in turn more functions. Understanding this type of functions takes training and practice in most cases, although it is also clear that there are people who understand this type of issues with great ease.
Finally, another of the great advantages of functional programming is concurrency and parallelism. Thanks to the computing power that currently exists, taking advantage of this is simple in functional programming because of the way it is structured.
In conclusion, functional programming can have many advantages, but it must also be analyzed under what conditions it is convenient to use it. It can be a very useful tool. However, before wanting to use some kind of paradigm for everything, one must question whether it is the best way to solve the task we are trying to complete.
Reference
Hinsen, K. (2009). The Promises of Functional Programming. Computing in Science & Engineering, 11(4), 86–90. doi: 10.1109/mcse.2009.129
Comments
Post a Comment