Unable to explain monad
No, this is not another attempt to explain the monads. I do not know how to do this and cannot imagine how, for example, from the present, I could explain this 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 inclined towards a functional approach. I do not think that this is possible at all. Practice easily solves this matter, but people rarely reach it.
I don’t even know how to answer simpler questions. Despite the fact that I have been writing on Scala for more than 3 years, I can’t explain on the fingers the benefits of language for a person from outside. For example, a couple of months ago I had a good discussion.
It all started with the question: “And for whom is your language written?” .
All these immunity, higher-order functions, a great type system, side effects and other monads revolved in my head, but I understood that this was not all that. The subsequent clarification finally sent me a knockout: “Here, for example, Java is a language for white-collar workers . ” That dialogue ended with some incoherent nonsense about the inability to explain the difference without practice.
This is not just a retelling of personal experience. All of us, users of functional languages, are in approximately the same 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, one can be angry at the limited conservatives who hawk “G”, calmly carry nonsense, retell myths and fairy tales to each other, firmly and confidently enter into discussions about things that they didn’t even spend a couple of hours on. You can also blame huge corporations with their teams of marketers.
But it seems to me, first of all, the problem is that we ourselves do not know how to sell FP. Yes, this is not an easy task. Although, when I remember how people make decisions, how and what things are included in the trends, I begin to think that this is possible.
There is always something wrong with development.
Not that I considered all of these industry craze bad. They just have a lot of flaws too. And not everyone knew how or how to cook them correctly. Missing or missing convenient tuning. However, these approaches have become “de facto” standard for the industry. And although the discussion about docker in production for some seems like an open question, everything has already happened.
I am sure the same thing can happen with functional languages. Yes, this is not entirely correct - to compare programming languages with methodologies and approaches. But we have something to borrow in their positioning for ourselves. All of them have a strictly defined problem that they solve. And this is speed: development, communications, planning, deployment, making changes ...
At the same time, from the point of view of positioning functional programming languages, it is difficult to say that they have a clear and understandable goal. Linguistic scholars “ FP vs OOP ” usually quickly slide into a measure of 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 composed ” often reinforce in people the opinion that they do not need this, than they inspire 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 development speed! And this speed is achieved by all these boring and frightening terms, concepts and properties that emerge from them. Lighter composition due to higher order functions - plus to 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, hotfixes and support. Well and so on, I think the logic is clear.
Yes, that sounds too simple and even obvious.
Yes, I didn’t say anything new here. But the importance of wording and emphasis is important. Unfortunately, this is how our thinking works. In order to break down barriers, explanations alone are not enough. Need practice! It is necessary that a person or company wants to spend time on this. References to “academicity” or relative beauty will inspire few to spend several days feeling like an idiot.
It’s worth stopping making smart people out of yourself, scattering right and left in terms of terms, proving the superiority of your favorite YP over Blub. Instead of proving the usefulness of feature X, it is much easier to use it as an explanation of some more understandable property. If other technicians have succeeded, perhaps it’s time for us to take responsibility as well and firmly come in with obvious and simple things.
So next time, with the difficulties of answering the question “ Why? ”, Do not hesitate to go with trump cards, such as: higher 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 inclined towards a functional approach. I do not think that this is possible at all. Practice easily solves this matter, but people rarely reach it.
I don’t even know how to answer simpler questions. Despite the fact that I have been writing on Scala for more than 3 years, I can’t explain on the fingers the benefits of language for a person from outside. For example, a couple of months ago I had a good discussion.
It all started with the question: “And for whom is your language written?” .
All these immunity, higher-order functions, a great type system, side effects and other monads revolved in my head, but I understood that this was not all that. The subsequent clarification finally sent me a knockout: “Here, for example, Java is a language for white-collar workers . ” That dialogue ended with some incoherent nonsense about the inability to explain 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 in approximately the same 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, one can be angry at the limited conservatives who hawk “G”, calmly carry nonsense, retell myths and fairy tales to each other, firmly and confidently enter into discussions about things that they didn’t even spend a couple of hours on. You can also blame huge corporations with their teams of marketers.
But it seems to me, first of all, the problem is that we ourselves do not know how to sell FP. Yes, this is not an easy task. Although, when I remember how people make decisions, how and what things are included in the trends, I begin to think that this is possible.
There is always something wrong with development.
- The processes are slow! And now, after a few years, every morning, in all the country's offices, people standing at the blackboard drag stickers from one column to another.
- Deploy is slow! And armed with devops values, we make 10 releases a day, while a new generation of admins fill it with tons of ruby, python and yaml.
- Applications are complicated! And so teams of 2-3 developers are building a new microservice architecture, thinking through the responsibilities of each service in detail and doing 10 pool requests for one small revision.
Not that I considered all of these industry craze bad. They just have a lot of flaws too. And not everyone knew how or how to cook them correctly. Missing or missing convenient tuning. However, these approaches have become “de facto” standard for the industry. And although the discussion about docker in production for some seems like an open question, everything has already happened.
I am sure the same thing can happen with functional languages. Yes, this is not entirely correct - to compare programming languages with methodologies and approaches. But we have something to borrow in their positioning for ourselves. All of them have a strictly defined problem that they solve. And this is speed: development, communications, planning, deployment, making changes ...
Why do we forget to say the most important thing?
At the same time, from the point of view of positioning functional programming languages, it is difficult to say that they have a clear and understandable goal. Linguistic scholars “ FP vs OOP ” usually quickly slide into a measure of 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 composed ” often reinforce in people the opinion that they do not need this, than they inspire 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 development speed! And this speed is achieved by all these boring and frightening terms, concepts and properties that emerge from them. Lighter composition due to higher order functions - plus to 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, hotfixes and support. Well and so on, I think the logic is clear.
Yes, that sounds too simple and even obvious.
Yes, I didn’t say anything new here. But the importance of wording and emphasis is important. Unfortunately, this is how our thinking works. In order to break down barriers, explanations alone are not enough. Need practice! It is necessary that a person or company wants to spend time on this. References to “academicity” or relative beauty will inspire few to spend several days feeling like an idiot.
It’s worth stopping making smart people out of yourself, scattering right and left in terms of terms, proving the superiority of your favorite YP over Blub. Instead of proving the usefulness of feature X, it is much easier to use it as an explanation of some more understandable property. If other technicians have succeeded, perhaps it’s time for us to take responsibility as well and firmly come in with obvious and simple things.
So next time, with the difficulties of answering the question “ Why? ”, Do not hesitate to go with trump cards, such as: higher development speed , cheaper support , fewer developers .
Ah, and more. Community events also play a significant role in positioning!
Therefore, we are waiting for all who are not indifferent to FP at the only functional conference in Russia - FPURE - Kazan - May 24-25 .
The program includes: Haskell, Scala, Elixir, Clojure, theory and practice, and of course many like-minded people with whom there is something to talk about!