D H wrote: > But what you are getting at is more akin to our mental model of what the > computer is doing when we write and run a program. Without a > fundamental understanding of memory and addresses, a programmer can make > certain mistakes that reveal this lack of understanding. But that > doesn't mean they have to learn about memory management at the very > beginning of their instruction.
Finally somebody who gets it :-) Every home handyman needs to know the difference between a claw hammer and a tack hammer and rubber hammer, and why you shouldn't use a claw hammer to knock dints out of steel sheeting, but they don't need to learn them all on the first time they look at a nail. I'm reminded about the concept "lies for children", used by Ian Stewart and Jack Cohen (mathematician and biologist respectively) in some of their books. The point they make is that much of what we teach each other -- even adults -- is "lies for children". The Earth is not a sphere, even though we can often get away with pretending it is. High and low tides aren't caused by the moon. Testosterone doesn't cause aggression. DNA is not a blueprint. And adding two strings together is not a simple operation, despite appearances. "Lies for children" in this sense are not *bad*, they are a necessary step towards a more sophisticated understanding. Imagine trying to learn about projectile motion if you needed to understand general relativity and friction just to get started. Now imagine you are a ballistic missile scientist, and you assume that the problem of firing a missile from here to there is independent of the shape of the Earth's gravitional field, air resistance and relativity. You've just missed your target by a kilometre. Ooops. Learning when you can ignore implementation details is just as important a skill as learning how to use variables. Just as you wouldn't try teaching closures to people who haven't yet learnt what a function is, you don't want to bog people down with implementation details too early -- but if you don't teach them *at all*, you are creating second-class programmers who will write slow, buggy, hard-to-maintain code. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
