Unable to explain monad
No, this is not another attempt to explain the monads. I do not know how to do this and I can’t imagine how I, for example, could explain it from the present to myself from the past.
The same applies to other FP concepts. I understand their value, how to use them. But I do not know how to convey this to people who are initially negatively disposed towards the functional approach. I do not think that this is at all possible. Practice easily solves this problem, but people rarely get their hands on it.
I do not even know how to answer simpler questions. Despite the fact that I have been writing on Scala for more than 3 years, I cannot explain on my fingers the advantages of the language for a person from outside. For example, a couple of months ago I had a chance to have a better discussion.
It all started with the question: “And for whom is your language written at all?” .
All these immunities, higher-order functions, a great type system, side effects, and other monads, were spinning in my head, but I understood that this was not all that. The subsequent clarification finally knocked me out: “For example, Java is the language for white-collar workers . ” That dialogue ended with some incoherent nonsense about the impossibility of explaining the difference without practice.
')
This is not just a retelling of personal experience. All of us, users of functional languages, are approximately in an identical situation. We perfectly understand the huge difference in comparison with Blub languages, but the rest of the world does not want to hear us. Of course, you can be angry at the limitations of the conservatives, who hawk “G”, quietly carry nonsense, retell each other myths and fairy tales, firmly and confidently enter into discussions about things that have not even spent a couple of hours. You can also blame huge corporations with their marketing teams.
But it seems to me, first of all, the problem is that we ourselves do not know how to sell FP. Yes, it is not an easy task. Although, when I remember how people make decisions, how and what things are included in trends, I start to think that this is possible.
There is always something wrong with the design.
Not that I thought all these craze in the industry were bad. They just also have a lot of flaws. And not everyone was able or able to cook them correctly. There was no or there is no convenient tuling. Nevertheless, these approaches have become “de facto” standard for the industry. And although the discussion about docker in production seems to some to be a non-closed question, everything has already happened.
I am sure the same thing can happen with functional languages. Yes, it is not entirely correct - to compare programming languages with methodologies and approaches. But we have something to borrow in their positioning for themselves. All of them have a strictly defined problem that they solve. And this is the speed: development, communications, planning, deployment, making changes ...
At the same time, in terms of the positioning of functional programming languages, it is difficult to say that they have a clear and understandable goal. The “ FP vs OOP ” tongues are usually quickly slipping into merit with features and concepts whose value is not well understood by the OOP camp. Articles and reports of the format “ You look at how these monads are superbly composited ” more often fix in people the opinion that they do not need it than inspire them to try. All these interactions rarely answer the question “ Why is this all? ". Beautiful and concise? Well, at best, fewer errors will be mentioned.
The most important thing in using functional languages is the same speed of development! And this speed is achieved by these very boring and frightening terms, concepts and properties that come out of them. Lighter composition due to high order functions - plus development speed. Immunity, in addition to reliability and fewer errors, is equivalent to giving more time for useful things, instead of spending it on debugging, hot fixes and support. Well, and so on, I think the logic is clear.
Yes, it sounds too simple and even obvious.
Yes, I did not say anything new here at all. But the importance of wording and accents is important. Unfortunately, our thinking is so arranged. In order to break down the barriers, explanations alone are not enough. Need practice! It is necessary that a person or company want to spend time on it. References to "academic" or to the relative beauty of few people will inspire to spend a few days, feeling like an idiot.
It is worth stopping to build wiseachers out of you, immediately scattering terms in terms of right and left, proving the superiority of your beloved PL over Blub . Instead of proving the utility of feature X, it is much easier to use it as an explanation of some more understandable property. If other technicians succeeded in this, it may be time for us to take responsibility too and to come in steadily from obvious and simple things.
So the next time, when the answer to the question “ Why is that? ” Is difficult, do not hesitate to come up with trump cards, such as: faster development speed , cheaper support , fewer developers .
The same applies to other FP concepts. I understand their value, how to use them. But I do not know how to convey this to people who are initially negatively disposed towards the functional approach. I do not think that this is at all possible. Practice easily solves this problem, but people rarely get their hands on it.
I do not even know how to answer simpler questions. Despite the fact that I have been writing on Scala for more than 3 years, I cannot explain on my fingers the advantages of the language for a person from outside. For example, a couple of months ago I had a chance to have a better discussion.
It all started with the question: “And for whom is your language written at all?” .
All these immunities, higher-order functions, a great type system, side effects, and other monads, were spinning in my head, but I understood that this was not all that. The subsequent clarification finally knocked me out: “For example, Java is the language for white-collar workers . ” That dialogue ended with some incoherent nonsense about the impossibility of explaining the difference without practice.
')
We do not know how to sell FP
This is not just a retelling of personal experience. All of us, users of functional languages, are approximately in an identical situation. We perfectly understand the huge difference in comparison with Blub languages, but the rest of the world does not want to hear us. Of course, you can be angry at the limitations of the conservatives, who hawk “G”, quietly carry nonsense, retell each other myths and fairy tales, firmly and confidently enter into discussions about things that have not even spent a couple of hours. You can also blame huge corporations with their marketing teams.
But it seems to me, first of all, the problem is that we ourselves do not know how to sell FP. Yes, it is not an easy task. Although, when I remember how people make decisions, how and what things are included in trends, I start to think that this is possible.
There is always something wrong with the design.
- Processes are slow! And now, after a few years every morning, in all the offices of the country, people standing at the blackboard drag stickers from one column to another.
- Slow slow! And armed with devops values, we make 10 releases a day, while the new generation of admins flood it with tons of ruby, python and yaml.
- The applications are complex! And now teams of 2-3 developers are building a new microservice architecture, carefully considering the responsibility of each service and making 10 pull-requests for one small edit.
Not that I thought all these craze in the industry were bad. They just also have a lot of flaws. And not everyone was able or able to cook them correctly. There was no or there is no convenient tuling. Nevertheless, these approaches have become “de facto” standard for the industry. And although the discussion about docker in production seems to some to be a non-closed question, everything has already happened.
I am sure the same thing can happen with functional languages. Yes, it is not entirely correct - to compare programming languages with methodologies and approaches. But we have something to borrow in their positioning for themselves. All of them have a strictly defined problem that they solve. And this is the speed: development, communications, planning, deployment, making changes ...
Why do we forget to say the most important thing?
At the same time, in terms of the positioning of functional programming languages, it is difficult to say that they have a clear and understandable goal. The “ FP vs OOP ” tongues are usually quickly slipping into merit with features and concepts whose value is not well understood by the OOP camp. Articles and reports of the format “ You look at how these monads are superbly composited ” more often fix in people the opinion that they do not need it than inspire them to try. All these interactions rarely answer the question “ Why is this all? ". Beautiful and concise? Well, at best, fewer errors will be mentioned.
The most important thing in using functional languages is the same speed of development! And this speed is achieved by these very boring and frightening terms, concepts and properties that come out of them. Lighter composition due to high order functions - plus development speed. Immunity, in addition to reliability and fewer errors, is equivalent to giving more time for useful things, instead of spending it on debugging, hot fixes and support. Well, and so on, I think the logic is clear.
Yes, it sounds too simple and even obvious.
Yes, I did not say anything new here at all. But the importance of wording and accents is important. Unfortunately, our thinking is so arranged. In order to break down the barriers, explanations alone are not enough. Need practice! It is necessary that a person or company want to spend time on it. References to "academic" or to the relative beauty of few people will inspire to spend a few days, feeling like an idiot.
It is worth stopping to build wiseachers out of you, immediately scattering terms in terms of right and left, proving the superiority of your beloved PL over Blub . Instead of proving the utility of feature X, it is much easier to use it as an explanation of some more understandable property. If other technicians succeeded in this, it may be time for us to take responsibility too and to come in steadily from obvious and simple things.
So the next time, when the answer to the question “ Why is that? ” Is difficult, do not hesitate to come up with trump cards, such as: faster development speed , cheaper support , fewer developers .
Oh, and more. Events for communities also play a significant role in positioning!
Therefore, we are waiting for all those who are not indifferent to FP at the only functional conference in Russia - FPURE - Kazan - May 24-25 .
In the program: Haskell, Scala, Elixir, Clojure, theory and practice, and of course many like-minded people with whom there is something to talk about!
Source: https://habr.com/ru/post/450132/
All Articles