Functional programming: measure seven times, cut once

Good day! Lately, I very often hear that the PLO has come down. 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, like 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 here to express themselves can not.

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 what we will lose from such a decision:

  1. Almost always, such solutions lead to boilerplate code.
  2. We lose 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 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 the OP is not always reasonable.

What is less surprising is that programmers often 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. Already 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 on a leading role in this project. Life is a success! And you just wrote a perfect service. Only one problem remains. What to do 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 much fP?


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 this 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 on any of these issues, then you can use them.

Thanks for attention!

Also popular now: