Actually, what grandmother got was something different: the problem of overloading the "=" operator with variable setting. If you instead use, for example, arrows (as Knuth does in TAOCP) the problem goes away, and grandmother is no longer confused.
As much as I'd love to imbue his grandmother (and by extension all grandmothers) with innate understanding of some programming principle that some seem to have trouble with I'm afraid this event or at least the authors recounting of this event does not lead to that conclusion.
The grandmother may not have been having trouble with the immutability of X. Her question was not "how can X be anything other than X?" It was "How can X be X+1?". Which could convey the more likely case of the unlearned coder not understanding the order of operation in program flow. I'm sure she understood that X could be assigned a value, I'm sure she even understood that X could be changed--what she was having trouble with, most likely, was how could you use X on the right hand side of the equator? How can you define a value with the value itself (Circular reference). And I can totally relate--when I first learned programming it was something that confused myself at first as well. I hadn't learned that the right hand side of the equator gets evaluated with X being resolved to it's "present" value which is then used to calculate the value and finally stored back in the variable.
I hate to be a downer, it certainly is a fond memory, but the initial supposition is inconclusive.
There are a few quotes from college I'll never forget. One of them was by my chemistry professor who said, "I have a great deal of respect for the equal sign."
He put one student's homework on the screen. Instead of answering:
A + B = C
C + D = E
she took this shortcut:
A + B = C + D = E
(Variables replaced for simplification.)
It was clear what she intended, but what she ended up with was a total fail.
Funny this post reminded me of a little incident and a great quote so many years ago. To this day, I still have a great deal of respect for the equal sign.
EDIT: I just realized that Professor State's class was one of the few that actually helped me develop good work habits for life. I once wrote about that here on HN:
Grandmother parses code as X == X + 1. Hilarity ensues as her confusion of the misapplication of the equals sign from math is later mistakenly attributed to a grasp of immutability.
The article mentions that grandmother was possibly a teacher, and it seems reasonable for a schoolteacher to be confused by programming's "variable x" vs. algebra's "unknown x", in addition to the confusion of "assignment operator =".
My mother (who is 68) started off programming with punchcards when she was working on her Masters in Economics, she eventually moved into executive work but still kept up her chops with Basic and Fortran well into the 1990s. Nowadays, she uses VNC to telecommute into work every morning to avoid having to deal with traffic.
If I had married earlier and had kids as soon as some of my schoolmates did --and my kids did the same in turn-- she could have been the great-grandmother of 20+ year olds.
I think we should almost be to the point in computer history where age-based archetypes/stereotypes of computer ignorance can be safely retired.
Actually, he points out his grandmother is well ahead of you fools since she has an intuitive understanding of immutable data structures and is distraught that one would modify state in-place like that.
In her head she probably thought, "hmm that's what the state monad is for" or something like "yeah that'll get you in trouble when you make your code multi-threaded".
Another nail in the coffin of the claim that imperative programming is more intuitive, persistently asserted without good evidence.
I submit that when people make claims of this sort, what they usually mean is actually "I'm used to doing it this way". Some actual studies of how new programmers learn would be valuable, and allow us to begin to evaluate claims like the above with at least a modicum of objectivity.
I don't think that referring to a single anecdote as a "nail in the coffin" of a position while complaining of the lack of "actual studies" in support of that position is terribly consistent.
The position I'm attacking is the claim that it's just obvious that imperative programming is more intuitive, not that it is more intuitive. By exhibiting counterexamples to this supposedly obvious assertion, it's shown that it is not in fact obvious. Whether imperative or declarative programming is in fact more intuitive is, of course, not something to be settled by the anecdote give in the link.
Sweat anecdote, however it has even less value than people realise.
If you want to explain an algorithm to Grandma, it's far easier to make her think at cookbook recipes -- X is a cup of sugar, now imagine that at every step you're adding one more cube of sugar to it.
