Pro OP # 2

There was a time when functional languages ​​were quoted, if not more, then on a par with imperative ones. The time has passed and it is even known why. For some reason, it is believed that programming in a functional language is a “brain explosion”. I don’t argue, sometimes it’s really an explosion, but this is literally a friendly clap on the ears, compared to brain explosions, which I occasionally have to try to figure out the source code in C #. I really want the story to be spiraling (-:



Divine Language of Mathematics ™



Somehow, humanity turned out that all existing programming techniques invented mathematics. It may be strange, but quite understandable, and the majority of fundamental, basic, carrier programming patterns are either procedural or functional. OOP came up with to facilitate the creation of large and complex systems. And if you look at the OOP theoretically - really, very convenient. This convenience collapses when the need arises to use third-party libraries (and it always arises). Great happiness, if the creators were good and sensitive people, took pity on your nerves and repeatedly drove their code through Unit tests, and even provided the entire economy with logical and understandable hierarchy. If they have not done so, the code becomes completely unreadable. In the "esoteric lispov" this situation is much better. All you need to know is the name of the library function, its parameters and what it gives on the output. Debugging such a system is much easier (including due to the absence of side effects ).



The myth of the unreadability and esotericity of the FP languages ​​is based on the difference in the perception of code by programmers. The emphasis in imperative languages ​​is placed on the “human, consistent perception” of the code. For example:

 int life ()
 {// let's start
     human Peter = new human ();  // Petya, please be born
     storage shelf = new storage ();  // Shelf, please appear

     Peter.Status = "Something good";  // Petya, you are well done
     Peter.getPie (shelf);  // Take the pie from the shelf
     return 0;  // We're fine here, we are done, thank you all
 } // finish

')

Functional languages, oddly enough, are no less readable. They simply describe not the process , but the decision , the result.

Here, for example, the function to turn the list (Erlang):

 reverse (List) ->
     reverse (List, []).

 reverse ([Head | Tail], ResultList) ->
      reverse (Tail, [Head | ResultList]);
 reverse ([], ResultList) ->
     ResultList.

It is difficult for perception by an untrained gaze, due to its recursive nature, but if you take a closer look at your chest , you can understand that here the direct text says: “The list came to me. I don't like him, I want to turn him over. I like the tail. I will keep it for myself, and glue the rest and set it aside. And if the tail is suddenly over, then I turned the list over and I can throw it away. ”

Periodically it is very difficult to understand, but where, in fact, does the action take place ? In my opinion this is a great Zen, to be able to write programs that work through definitions.