Functional programming: measure seven times, cut once

Good day! Recently, I very often hear that the PLO has come to a decline. Today, more and more people are switching to a functional paradigm. Soon, people who write in C ++ / C # / Java will not remain at all. Is it so? I do not think. In my opinion, thoughtless use of OP (functional programming) can be time consuming and an extra headache, which is completely incompatible with current design solutions. Let's make sure of that!



I want to note: this is not about lambda expressions in Java / Python, but about more advanced OP, such as Haskell or Scala with cats / scalaz.

So, I argue that:
')

1. OP is far from being applicable everywhere.
2. Brings a headache when integrating with ready-made solutions.
3. Spending time on AF is not always reasonable.

Let us examine these points in more detail and estimate the scale of the tragedy.

1. OP is not applicable everywhere

It seems surprising, but not everyone understands this. Moreover, languages ​​like C are very far from their sunset. Much further than Haskell or Scala. Take a look at any game engine. With a probability of 90%, most of it is written in C. Look at the firmware of any home appliance in your apartment. Most likely, this is C again! Operating Systems? Of course, S.

Why is this happening? The fact is that all of the above works directly with iron. Iron does not know any higher order functions. Iron is a set of registers (which is already a changeable state), interrupts (again, which change state) and commands that transfer zeros and ones from one cell to another.

Of course, you can use abstraction and forget about all these iron things. But first, it is not always reasonable. If our program is simple enough, then there is no point in closing with some layers of abstraction. Secondly, often in such programs the speed of work is put on one of the key positions. Therefore, the additional cost of “explaining” the AF gland will completely ruin the benefit of your development. OP can not express itself here.

2. Brings a headache when integrating with ready-made solutions.

Every self-respecting programming language has a large number of ready-made solutions. In C #, for example, this is the Entity Framework and .Net. In Java, these are Hibernate and Spring. And almost every framework aims to work in our usual OOP style. Almost always, these solutions have changeable states and are completely unsuitable for working with pure AF.

Any hardened functional programmer will say that you need to throw out these solutions and work without them. Okay. Let's just estimate for the sake of reference what we will lose from such a decision:

1. Almost always, such solutions lead to boilerplate code.
2. We are losing a huge layer of functionality. Of course, we can take a ready-made library to work in the functional paradigm. But almost always, such a solution is much less popular, and therefore can not offer half of all the possibilities of popular solutions.
3. The finished products that use this solution will need to almost completely refactor.
4. We lose a well-tested and well-determined solution. Instead, we go to the unknown. Are there any popular problem solutions? Of course! But about them, as a rule, everything has long been known. In our new approach, this will not be exactly.

In fact, the list can be continued for a long time. In my opinion, the totality of losses makes the FI, at least, not everywhere and not always suitable.

3. Spending time on FP is not always reasonable.

What is surprising, however, often programmers do not see what is behind the code. Not always the programming language and the paradigm determine the quality of the product. On the back, everything goes to containerization. It is almost no matter what you write: Python, Java, Scala. The code in any of these languages ​​can be wrapped in an image and delivered in a container.

In such a world, it is not so important that inside the container, if it meets all the requirements. Here it is more important how the whole system is organized. The question arises: are you really sure that your time should be invested in the study of the OP with its category theory? Perhaps it is worth investing in the development of a common system architecture. In addition, it is much easier to find people without knowledge of FP who are ready to provide you with such containers.

Imagine such a situation. You sit at night and study the whole theory. You watch videos on YouTube, read books, delve into mathematical calculations. Over time, you can already build a small application, but all is not clear. You start practicing further: you take more advanced books, go to meetings, talk with colleagues about high. But then came the real project. With your knowledge, you will take the lead in this project. Life is a success! And you just wrote a perfect service. Only one problem remains. What to do with it next? How to set up an automation process? How to set up smart balancing? How can another service find yours? You may simply not have the answer to these questions! Are you still sure that you need so OP?

findings

In fact, I am very positive about FP. All I want to say is a tool that does not always and everywhere fit. In my opinion, the engineer should not think like / dislike categories. Instead, there should be the most objective reasons for using a particular solution.

Before studying / introducing a functional paradigm, you should ask at least three questions: the possibility of applying in your professional field, how expensive it can affect when integrating with ready-made solutions and whether the time and resources spent will be paid back. If you do not have a panic attack from any of these issues, then you can use them.

Thanks for attention!