My original reason to run this blog was to promote a certain vision of programming. In particular, I want to prove that programing can and should be more like speaking than tinkering, and that more emphasis should be put on expressing ideas in a comprehendible manner, than on developing working systems. This view may seem controversial, because --in the parlance of our times -- it's "the working systems that deliver business values" -- but I think that many valuable projects may have sunk because they got to the point where there was noone available to further maintain them at their complexity level.
And the reason for that is that it is usual that programmers treat programming as tinkering. There are unimaginably many ways to solve programming problems (or -- how Larry Wall would put it -- There Is More Than One Way To Do It).
Interestingly, although Larry Wall has linguistic background, there are so many ways he got wrong in his Perl programming language.
The people focused around Python deliberately took an opposite approach to Larry's -- they say that there should only be one legitimate way to do some things. Although it is inevitable that programming languages would allow many ways to do the same thing -- just as there are many ways the same thought can be spoken -- only the most obvious solutions should be prefered in the long run, and the remaining ones should be discouraged.
This is something that programmers had to learn for a long time, and I think that it still isn't obvious to the majority of them. The reason is that initially it was common to use assembly, or perceive a computer program as a set of commands, rather than a description of itself.
The value of functional programming is not that it allows to form very abstract and difficult to comprehend notions, like Haskell's monads or lenses. (Actually I think that this is a dangerous extreme that should be discouraged in everyday practice). The functional programs are descriptions of systems, rather than sets of commands. Functions and immutable objects are like words or notions. You can do no harm with words or notions. They don't change anything in the world; only actions do. And while actons are inevitable in real-world programming, functional programming teaches to be careful with actions.
Imagine a situation that your words cause side effects. You say, for instance, "Those blue flowers in the garden are beautiful". And each of those words has a side effect associated, for example, uttering "blue" causes windows to open, uttering "flowers" causes lights to switch, and so on.
It would be weird. But this is normal for some programs, whose authors didn't internalize the notion of functional programming.
And the reason for that is that it is usual that programmers treat programming as tinkering. There are unimaginably many ways to solve programming problems (or -- how Larry Wall would put it -- There Is More Than One Way To Do It).
Interestingly, although Larry Wall has linguistic background, there are so many ways he got wrong in his Perl programming language.
The people focused around Python deliberately took an opposite approach to Larry's -- they say that there should only be one legitimate way to do some things. Although it is inevitable that programming languages would allow many ways to do the same thing -- just as there are many ways the same thought can be spoken -- only the most obvious solutions should be prefered in the long run, and the remaining ones should be discouraged.
This is something that programmers had to learn for a long time, and I think that it still isn't obvious to the majority of them. The reason is that initially it was common to use assembly, or perceive a computer program as a set of commands, rather than a description of itself.
The value of functional programming is not that it allows to form very abstract and difficult to comprehend notions, like Haskell's monads or lenses. (Actually I think that this is a dangerous extreme that should be discouraged in everyday practice). The functional programs are descriptions of systems, rather than sets of commands. Functions and immutable objects are like words or notions. You can do no harm with words or notions. They don't change anything in the world; only actions do. And while actons are inevitable in real-world programming, functional programming teaches to be careful with actions.
Imagine a situation that your words cause side effects. You say, for instance, "Those blue flowers in the garden are beautiful". And each of those words has a side effect associated, for example, uttering "blue" causes windows to open, uttering "flowers" causes lights to switch, and so on.
It would be weird. But this is normal for some programs, whose authors didn't internalize the notion of functional programming.
