It's interesting that this gets highlighted as an example that baffles the 'non-programmers':
int a = 10;
int b = 20;
a = b;
This looks obvious to an experienced developer, but it is a clear-cut case of horrible notation. The first two uses of '=' are mere variable bindings, whereas the third is a mutation. Using '=' for bindings is dubious but defensible, since
int a = 10
does indeed guarantee that a = 10 in a mathematical sense. Using '=' for mutation is crazy, though, since assignment isn't commutative:
a = b
and
b = a
are not equivalent. The pinnacle of confusion can be seen in the following abomination:
x = x + 1
This looks like an algebraic equation with no solution. So, you take people who have been taught to use '=' for mathematical equality their whole lives, and now they're supposed to swallow these absurdities? No wonder people are confused.
What we're seeing here is essentially a pun: the use of '=' for at least three different things (binding, mutation, and mathematical equality). To my knowledge, only Lisp gets this right (although there must be others). For example, in Scheme we would have
(let ((a 10)
(b 20)))
for bindings,
(set! a b)
for mutation, and
(= a b)
for equality comparison—three ideas, three different notations.
I'm certainly prepared to believe the hypothesis that some people will just never 'get' programming, but we should consider the possibility that bad notation is part of the problem. Given how entrenched it is, changing notation might be unwise, but at the least we can acknowledge and explain ambiguous notation rather than treating it as self-explanatory.
His insight was that x = x + 1 isn't contradictory once you recognize that the two x's have implicit temporal subscripts. That is, "the value of x at time t+1 = the value of x at time t, plus 1". Make that temporal dimension explicit in the language and you can go back to having a nice equational semantics.
It's interesting, though, and perhaps germane to your point, that this insight turned out to lead far away from mainstream languages.
I've come to the conclusion that math and programming are very different things because math isn't executable. Programs have to run on a physical machine, math doesn't. The "physical" part changes everything. As someone pointed out in a blog post recently, even programs written in the purest most side-effect-free languages have side-effects when they run. I suspect that functional programming ultimately runs aground on this discrepancy - i.e. on the intrinsic imperativeness of the machine. The "x = x+1" paradox can be seen as a distillation of this imperativeness.
Perhaps we should teach programming not as math but as a kind of mechanics.
What we're seeing here is essentially a pun: the use of '=' for at least three different things (binding, mutation, and mathematical equality). To my knowledge, only Lisp gets this right (although there must be others). For example, in Scheme we would have
for bindings, for mutation, and for equality comparison—three ideas, three different notations.I'm certainly prepared to believe the hypothesis that some people will just never 'get' programming, but we should consider the possibility that bad notation is part of the problem. Given how entrenched it is, changing notation might be unwise, but at the least we can acknowledge and explain ambiguous notation rather than treating it as self-explanatory.