Software solutions are becoming complex, and it is necessary to structure them very well for future maintenance and extension. Software engineers try to modularize software into smaller pieces and abstract away complexities in different pieces and layers. Dividing the code into smaller pieces makes it possible to tackle each problem individually. This approach improves collaboration because different engineers can take responsibility for different pieces. Also, they can work on specific parts of the software without being concerned about the other parts.
Dividing software into smaller pieces is not the biggest challenge in most projects and programming languages. For instance, in object-oriented programming (OOP), software is divided into smaller pieces such as packages, classes, interfaces, and methods. Engineers tend to divide the software into these building blocks by domains, logic, and layers. Classes are recipes to create instances and objects. As the name suggests, the most important building blocks in OOP are objects. Engineers deal with objects, and the role and responsibility of them should be clear and understandable.
In OOP, connecting the building blocks to each other is not as easy as dividing them. Connection between different objects may propose strong coupling between them. Coupling is the biggest source of complexity in OOP. A change in a module or class could force change in all coupled modules and classes. Also, a particular module or class might be harder to reuse and test because of coupled modules or classes.
Software engineers try to loosen coupling by structuring the software well and applying different principles and design patterns. For instance, single responsibility, open-closed, Liskov substitution, and interface segregation and dependency inversion (SOLID) principles, when applied together properly, tend to make software easy to maintain and extend.
Even though it is possible to decrease the coupling and simplify software structures, managing the memory, referencing to instances, and testing of different objects remains difficult because, in OOP, objects are open to change and mutation.
In Functional Programming (FP), pure functions are the most important building blocks. Pure functions do not rely on data outside of themselves and they do not change data that exists outside of them; in other words, they do not have side effects. Pure functions are easy to test because they will always provide the same results.
Pure functions can be executed on different threads or cores without any mechanisms to handle multithreading and multiprocessing. This is a very important benefit of FP over OOP, as multicore programming mechanisms are very complex to handle in OOP. Also, programming for multicore computers is becoming more important day by day because hardware engineers have finally hit the limit of the speed of light. Computer clocks will not be getting faster in the near future, so in order to have more cycles per second, hardware engineers are adding more processors to chips. There seems to be no end to how many processors we will have in our computers. A larger number of processors to be used for a program means a more complex multithreading and multicore mechanism to handle it. FP eliminates the need for a complex multicore programming mechanism as pure functions are not dependent on any instances or data outside of themselves. It is easy to change pure functions without changing other parts of the software.
FP embraces immutability and stateless programming, and makes applications easy to maintain and extend, as managing states and tracking mutation in code is not a trivial task. In fact, Facebook, in the documentation of immutable.js, a framework that brings immutable data structures to JavaScript, states that "Much of what makes application development difficult is tracking mutation and maintaining state."
FP is a declarative programming style, so functionally written code declares the operations, expressions, and what needs to be done. Declarations are easy to trace and less verbose as, opposed to imperative programming, which sends orders to the compiler, it is verbose and hard to trace. Embracing immutability and being declarative makes applications easier to maintain and extend. We will look into examples of declarative versus imperative programming later in this chapter.
