I'm on board with his basic pedagogical point: don't tell people you expect them to struggle.
I'm concerned that he's going a little too far in the other direction, though. It's great to come up with a simple or even tautological explanation for concepts. However, those explanations don't address the nuances of why those concepts challenge people in practice. And telling someone it's easy when s/he actually is struggling is just as dangerous.
When I was learning C, I absolutely understood that a pointer pointed to something, and I wasn't bogged down by people telling me it was hard. That didn't stop me from dereferencing null pointers, returning addresses to variables on the stack, getting confused when someone added to a pointer, etc. The aptitude that Joel wrote about and Jon derides isn't the aptitude of applying a metaphor to code. It's the aptitude of coalscing a set of program behaviors into a mental abstraction that is more than "a pointer points."
I spent hours trying to help a friend in college "get" enough assembly language to not fail a class. I had already done assembly language development professionally and had previously gotten an A+ in the class, so I understood the concepts well, and I explained them from a dozen different directions.
I don't care what the OP says. This guy was simply not capable of understanding the concepts. Maybe at some level he was, and he had some kind of psychological blinders on that prevented him from getting what I was saying, but he really, really didn't get even the most basic concepts. And when it comes down to it, it doesn't matter whether he has some innate ability that he can't tap -- if he can't do it, even with lots of help, then he can't do it.
While I was helping him, others from the lab came over repeatedly to ask me for help, assuming I was the lab assistant. I WAS able to help a half dozen other students understand their program.
It was his third attempt at taking the class. He finally gave up and changed his major, IIRC.
No, not x86. I actually can't remember the actual CPU it was. Something I'd never heard of, nor run across since. Maybe an IBM mini CPU? We would log into the computer via terminals and build and test that way. This was in the late 80s.
I remember that it was a pretty straightforward architecture, though. Something like 68000, which I knew already, but it was even more orthogonal with respect to addressing modes. I think it had 16 32-bit registers, and you could use any as an address to load data from, complete with offset for easy manipulation of data structures.
I do know x86, and while the 8086 was designed by idiots, it's not that hard to get the basics. Segment registers are a PITA, but as long as you're using 32-bit mode and not accessing more than 4Gb at a time, you can mostly ignore them. I've had to deal with something similar in another architecture, and you just end up with abstractions that hide the details as much as possible. Same as coding anything else that's nontrivial, really.
My point is that a memory reference is a conceptual reference. There is no difference. Understanding references is not about building abstraction atop your understanding of them; it's about recognising that you can express natural abstractions literally through them.
I'm unclear on what it means to "understand references" in a way that doesn't involve the way they behave in code. Unless you're saying that the concept as it appears in code can be explained entirely with the tautological definition, in which case I would be inclined to disagree.
Of course, I'm also not sure that Joel's suggestion that some people have an aptitude for such understanding is "irresponsible." If you were to say he underestimates what people can pick up with practice, that would be a different story.
I just think he comes too close to saying that it's entirely the onus of the student to understand the concepts, when the other half of the problem is that they're being taught (in my humble but loud opinion) incorrectly.
I agree with this completely. It's one thing for the concept itself to be hard to understand. It's another thing for the concept to be simple, but proper execution to be tough, frustrating, and prone to error.
This is a really important distinction; I see a lot of people claim they don't understand something because implementation is hard. Sometimes implementation is just hard. They should note this more often in schools rather than taking an extreme position of self-esteem/whatever.
I'm concerned that he's going a little too far in the other direction, though. It's great to come up with a simple or even tautological explanation for concepts. However, those explanations don't address the nuances of why those concepts challenge people in practice. And telling someone it's easy when s/he actually is struggling is just as dangerous.
When I was learning C, I absolutely understood that a pointer pointed to something, and I wasn't bogged down by people telling me it was hard. That didn't stop me from dereferencing null pointers, returning addresses to variables on the stack, getting confused when someone added to a pointer, etc. The aptitude that Joel wrote about and Jon derides isn't the aptitude of applying a metaphor to code. It's the aptitude of coalscing a set of program behaviors into a mental abstraction that is more than "a pointer points."