[lostcolony]

I think it's actually as much to do with having to turn syntax and abstraction into something actionable that describes the solution.

That is, in programming you learn a small set of abstractions (programming language syntax), and the actual coursework in applying that is in how they combine, how to fit them to problems.

In math, you learn a large number of abstractions (notation), that can vary and have new ones across different domains, and which doesn't tell you what it is doing unless you learn all the abstractions.

The latter you can kinda get, if you think about it, but forcing you to actually turn it into something expressed in the former means it is synthesized into something applicable, rather than just abstraction that may or may not be.

That is,

http://upload.wikimedia.org/math/d/f/1/df17b3410e58ac4c285bc...

is harder to understand when you come across it than

  total = 0;
  for(i = 0; i<=100; i++)
  {
     total += i;
  }
  return total;

or

  sum([1..100])

You have to convert the first from a symbol that does not describe its action, to an action; the code describes the action. That extra translation step leads to additional cognitive load when learning, at least for me.

[ohquu]

Alternatively, you could just note that your example reduces to 100*(100+1)/2. This simplification decreases cognitive load even more substantially! Taking a strictly programmatic view of a problem allows you to be lazy, and I believe that you lose a lot in the process. There is importance (numerically, even!) in thinking about things in a more formalized, mathematical way.

[gergoerdi]

But your second code snippet is almost a verbatim transliteration of the image URL, so in what sense is it easier to understand?

(verbatim transliteration would be

    sum (map (\i -> i)) [1..100]

)