I had a similar experience when helping a friend with a bug in his code from an introductory programming course at my alma mater. The programming assignment inv

I had a similar experience when helping a friend with a bug in his code from an introductory programming course at my alma mater. The programming assignment involved manipulation of an array of data in C, and there was a counter variable involved to keep track of which element of the array was currently being manipulated. He understood that there was a relationship between the array and the counter variable, but he took the relationship to far. He thought that the counter variable needed to represent the element of the array, and so he was assigning the value of the particular element in the array to the counter variable. In his mind, the counter variable didn't just provide the element number to look for; it was the element he was looking for, or at least it needed to become so. Both this, and the color example provided by the author, demonstrate how many implied relationships we depend on within the programs we write, and how many people believe that those relationships to be explicitly stated or else the compiler won't understand what we mean. I don't think I was able to get my friend to really understand what was going on and why we couldn't just 'tell' the computer to 'relate' these two things for us. It was a level of such naive concreteness that his mind just fought against descending to. I wonder how someone might educate people in thinking at this level? The optimist in me says it might be possible; the pessimist suggests that it might be in the same realm as trying to get people to understand pointers and recursion, which enough people I've read suggest is extremely hard for some (many?) people to understand.