Being a mathematician, programmer and psychologist, I can hardly believe that you can rip math notation apart from math itself. To be fluent with math one needs three "languages" which her mind can use in parallel to think about math problem. Its math notation, English (or any other natural language) and visual mental image. If any of such a mental languages is not available to a person, or if he is unable to translate from one to other, then he would struggle with math.
That is basic, I didn't touch math 15 years and still now that.
I got the meaning presented in the article because I've practiced the notation presented, but wouldn'nt have figured it out instantly otherwise.
We have different programming language syntaxes for a reason.
Math would be an entirely more enjoyable subject if it were communicated in more practical terms that can be executed on a CPU.
There are so many interesting objects in math that cannot be executed on a computer. You could define the set of permutations of the naturals, for example, which is an infinitely large set; there's no algorithm you can execute which could produce such a set on your computer. Math would be severely limited if it could only deal with things that were computable on your workstation.
You can have math that is entirely computational -- it's called constructive math -- but the result is a very different math. For example, in constructive math, all functions over the reals are continuous, and not all subsets of finite sets are finite.
Classical math is concerned with relations between "preexisting" objects. The statement 4 + 5 = 9 does not mean that the numbers 4 and 5 are added by some algorithm to construct the number 9, but that the three numbers are related via a ternary relation. The statement 9 - 5 = 4 is an equivalent statement in classical math, expressing the very same relation, but means something radically different in computer programs. I think it's important for computer scientists to understand this difference.
Jean-Yves Girard, the inventor of system F in functional programming discusses this difference in Proofs and Types[1], in the very first section, called "Sense, Denotation and Semantics".
The edge case of summing infinite sequences has no practical application in CS.
The number 2 is \Sigma_{n=0}^{\infty}1/2^n. So you're "using" sigma every time you use the number 2, which may be practical in some programs.
The fact that you can't write a program that sums an infinite sequence using an infinite number of computational steps doesn't mean uncomputable objects have no practical application. In fact, the formalism Lamport talked about in his lecture makes common use of them, and you do, too, every time you use floating point arithmetics. When you use floating point numbers, it's very convenient to think of them not as the very complicated objects that they are, but as a real number (an uncomputable object) with some error term; in fact, that's how floating point is thought of in the design of many numerical algorithms. In other words, objects that are directly representable on a computer, are often conveniently thought of as approximations of uncomputable objects. If you can't write what the non-computable object is in a language designed to assist in reasoning about how algorithms work -- which is the subject of Lamport's talk -- you're making life much harder for yourself.
Another problem of thinking of summation as a for-loop is that it makes you think of the definition as an algorithm, which it isn't. For example 4 * 5 = \Sigma_{i=1}^{5}4, but both of them are just different representations of the number 20. In a program it may make a big difference if you're writing 20, 4 * 5, or `for(i in 0..4) sum+=4`. In mathematical notation, all three are the same. It's not like one uses a cheap multiplication operation and the other an expensive for-loop.
It usually only seems like bad notation if I am misunderstanding things.
{f ∈ [1..N ⟶ 1..N]| ∀ y ∈ 1..N: ∃ x ∈ 1..N: f(x)=y}