[ab-irato]

I've yet to finish my way through. But it is amazingly precise and thorough. There are a few mistakes that the reader catches easily if they've been paying attention.

The authors are really onto something with programming as a means to learn other subjects. I know there is a very recent book on differential geometry topics from them also!

Would you happen to have proof of property d of exercise 1.33 lying around? (The one on the Euler-Lagrange operator of a composition of Lagrangian-like functions)

[mathattack]

The authors are really onto something with programming as a means to learn other subjects.

I think this is because of the precision that programming demands. You have to really nail down every edge case, and think about things down to their essence.

This is one reason why programmers can succeed in jumping the fence to work in their customer's jobs, even when it's an unrelated field. (I've seen many programmers make swaps from fields as diverse as brand management, telecom customer support and bond trading)

[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]

)