Are the brains of the UNIXoid working correctly?

Today I saw the topic. sum-even-numbers-1-100 At that time, it was already closed but not the point. Other thoughts came to mind.
All newcomers to Haskell are afraid that when they study it, their brains will turn inside out. I did not notice anything like that. And all because the brains of all Unicsoids are initially in the correct position. Let's look at an example concerning this theme.
On Haskell you need to write one line.

print $ sum [0,2..100]

But analogue on bash

echo $(($(seq -s+ 0 2 100)))

In programming only one half (and probably even the less significant half, for that matter) is about coding techniques. Much more important is to understand what you do and to understand the "structure" of the problem you are working on:

Now, this will work as expected and of course produce the correct result. Who could argue with that?

Let me tell you a story: the young Friedrich Gauss was attending grammar school (as far as i know the story he is purported to be 7 years old) and one day the teacher didn't feel like teaching, so he assigned the class this task: calculate the sum of all integers 1-100. He expected that the pupils will be busy all day doing all the additions. But 10 minutes after the assignment Gauss turned in his work - and earned a solid slap in the face for obviously not doing what the teacher told him to do.

Anyway, the slate (they wrote with chalk on slates) was put on the teachers desk face down and the other pupils were for a long time busy adding and adding. After some time one after the others were turning in their results and the slates were stacked face down. Finally the teacher controlled the results, taking one slate after the other and all were written all over with intermediate results - some wrong, some correct, but that is not really the point.

Finally he got to Gauss' slate there were no intermediate calculations, just a result: 5050. Bewildered he asked Gauss how he came to this result (which is correct, btw.) and in the little time he spent. Gauss answered:

Let us take the first number (1) and the last number (100) and add them: we get 101. Now take the second and the penultimate number and the sum is also 101. And so on, we get fifty pairs (1+100, 2+99, ... 50+51) each adding up to 101. We multiply therefore 101x50, which is easy to do in the head and arrive at 5050 - q.e.d.

You see, programming is about identifying such properties. I once had to correct such a "i have no idea what i am doing"-way of implementing something. The solution there was obviously "outwardly" absolutely correct but equally obviously neglected basic properties of the ways things work.

If you don't understand applied mathematics at least to some degree you simply don't have what it takes to do programming, regardless of which language you try. I always wonders how "computer science" can be a science at all. A computer is a tool and you have to learn how to use it properly, but that is not a science, it is a trade. As there is no "hammerology" but simply blacksmithing there is no "computer science". There is, though, a number of sciences related to it (mathematics being one of these, language theory being another) and as i see it the problems in modern software development come from gravely ignoring this aspect of writing programs.

bakunin

T=0 ; for X in {2..100} ; do ((T+=X)) ; done

Loses at code golf, but wins in a world where code must be read, understood, and maintained.

More seriously, Haskell won't replace shell, they've got different jobs. Haskell's real opportunities are perl and python, two omnipresent languages ill-equipped for formal math/logic but often pressed into service with the assistance bolt-on modules. This works but the syntax of calling modules for something you'd expect a builtin to do is inevitably ugly. Something with more orthogonal data structures could do a lot more with a lot less kludge. What can Haskell's data structures do?

OpenSCAD is another purely functional language, though it doesn't look it at first. It looks more like C, with very different constraints on where you're allowed to do what. This causes a bit of brain damage at first ("why can't I overwrite variables!?" cried a million voices) but is good at illustrating what "functional language" means in a paradigm procedural programmers can understand. It's also got a nice orthogonal set of basic vector/matrix operations.

Having fought through and learned its ways, I agree that functional syntax is often simpler and more concise. It's rarely clearer -- comments are essential. And never in my experience have they ever been faster or smaller. Functional languages rely on things like compiler optimization and caching to reduce the amount of work for a given result. This amounts to big compilers/interpreters and occasionally unpredictable amounts of overhead. Tail recursion is a wondrous thing but so easy to poison!

That's the price you pay for a language one step closer to declaring what you want instead of declaring exactly how to do it. It's not a good fit for everything.

Thanks to @Corona688 and @bacunin and everyone who was interesting. To top it all I want to add.
This is a side effect, so to speak, but it may be equally useful.
I tried to learn English from fiction books, but this is a very tedious thing. Because a lot of incomprehensible. Difficult speech turns, tenses of verbs, etc. I was looking for such a lite book and without ambiguity. Haskell is in itself an interesting language and therefore I read this book and learn English with great pleasure. Anyone who needs to tighten up English I advise you to download the book "Haskell_eBook_Reader.pdf"
Well, or maybe this approach in relation to something either seems interesting.