The functional approach and OOP are often contrasted. But it’s not entirely clear why? What makes functional programming different? Lambdas and having functions like map, fold, reduce, etc.?
OOP introduces artificial objects, describes them and the environment creates classes and inheritance of properties, and tries to solve the problem in this artificial cloud. Functional programming (FP) tries to find a function that would describe the solution to the problem and translates it into a simple programming syntax. Neither methodology provides direct answers. And each of the approaches solves some problems better and some worse.
Integrating various out-of-the-box functions into the OOP model helps speed up work but increases the vulnerability to hacker attacks. FP controls everything and is less vulnerable, but the quality of execution depends on the proficiency of the developers.
It is wrong to think that functional programming is bad or weak. Moreover, the language syntaxis is the basis of any programming solution, is pretty simple. But the representation of the very concept of static variables and their strong typisation demands from the programmer to work out the logic of the software system in advance. So, it’s more demanding in comparison to how OOP works, letting to change some types and numbers on the go.
Functional programming is often opposed to OOP mainly because the wave of hype created at one time around Java and C ++ went in the opposite direction and now works for Haskell or Rust popularity. It turned out that template libraries and multi-level object hierarchies did not solve all the problems. On the contrary, they created new ones. The complexity of software systems is still growing uncontrollably, and, accordingly, their cost. Here we are witnessing the rational appeal of the industry to the fundamentals, with the goal of reducing entropy.
In an imperative approach, you need to describe each step in detail and calculate all the figures in the correct sequence. In functional, it’s simple: if you found the function, which can describe the solution, you do not need the myriads of iterative calculations; here’s a function for you – get the result at any point of the curve.
Also, the “lazy way” is actively used in the functional approach, when some functions may not be requested until they are really needed.
It’s a holistic approach. For example, in the imperative style, it is customary to make mutable variables, while in the functional style, it is customary to use immutable variables and pure functions (those functions whose result depends only on input parameters and does not depend on anything else. Change the environment in any way, and since their result does not depend on external parameters, their result can be cached or computed in parallel without problems).
In opposing OOP and functional, the problem is narrowed down to opposing who manipulates whom, either functions or mutable objects. But that’s too narrow a view: Objects can be functions, and functions can store values. Imperative programming became popular due to the relatively easy translation of such programs to popular processor architectures, on which it in a functional style does not show particularly outstanding results. But programs on mutable states (objects) cannot be scaled unless additional mechanisms for load distribution (across cores, computers, networks), resource sharing (files, shared memory zones), and mutual communication to obtain work results are introduced in advance. The question is different – can functional programming simplify the solution to this heap of problems?! Yes and no. A high-level functional SQL representation helps distribute the load on relational databases, but we are not talking about linear growth from the number of cores. The high level of OpenGL allows you to write programs that perform gigantic amounts of calculations, even in imperative languages (as it was created), distributing the load on the GPU cores. But the lack of resources has been and remains the bottleneck of any program for any operating system. And communications are just approaching the solution of these problems, and imperative languages try to solve them in a functional style, completely abandoning the management in the “manual” style of “states.”
This was my personal impression of how everything works, if you wish to see a professional view, visit some of the functional programming evangelists, like Serokell.io. They are open to dialog on the expert level.