"Online Python Tutor is a free educational tool that helps students overcome a fundamental barrier to learning programming: understanding what happens as the computer executes each line of a program's source code. Using this tool, a teacher or student can write a Python program directly in the web browser and visualize what the computer is doing step-by-step as it executes the program."

"helps students overcome a fundamental barrier to learning programming: understanding what happens as the computer executes each line of a program's source

While the tool and the approach itself seems nice, I still think that it's done backwards. The students need to be explained and taught how a computer works, how code is executed, what happens when a program runs, how and what instructions do, and then the barrier will not exist anymore. Such tools can be useful in explaining all that, for sure, but not as a programming-learning tool, more a programming/language-understanding tool. "

I don't necessarily think that's the best approach for everyone. Starting at the high-end helps ease the student into thinking in an appropriately structured way. There is a certain barrier in understanding just how rigidly things are interpreted, and just how generic the building blocks are - and how to structure something to get the intended results. With that in place, digging deeper is easier: If you can understand not-entirely-trivial python programs, it's possible to understand (roughly!) how the python interpreter has to work, and from there on to "it's also (maybe indirectly) (sys-)calling the kernel to get certain things done" isn't a giant leap. The details of what makes the kernel special (memory mapping & swapping, interrupts, locking, IO, etc.) follow naturally, and somewhere in that it makes sense to look at how a CPU actually works.

Starting top-down does probably lead to more sloppy programmers, since they might not care as much about the lower levels when they feel they can already do something useful. Starting bottom-up will probably bore some potentially good future programmers to death (since they won't see the use yet), and does probably lead to more myopic programmers (the microöptimization above structure - type).

And no, I'm really not sure what the best solution is. "Everything at once" would be great, but that might not be completely doable...

I don't necessarily think that's the best approach for everyone. Starting at the high-end helps ease the student into thinking in an appropriately structured way. There is a certain barrier in understanding just how rigidly things are interpreted, and just how generic the building blocks are - and how to structure something to get the intended results. With that in place, digging deeper is easier: If you can understand not-entirely-trivial python programs, it's possible to understand (roughly!) how the python interpreter has to work, and from there on to "it's also (maybe indirectly) (sys-)calling the kernel to get certain things done" isn't a giant leap. The details of what makes the kernel special (memory mapping & swapping, interrupts, locking, IO, etc.) follow naturally, and somewhere in that it makes sense to look at how a CPU actually works.

Starting top-down does probably lead to more sloppy programmers, since they might not care as much about the lower levels when they feel they can already do something useful. Starting bottom-up will probably bore some potentially good future programmers to death (since they won't see the use yet), and does probably lead to more myopic programmers (the microöptimization above structure - type).

And no, I'm really not sure what the best solution is. "Everything at once" would be great, but that might not be completely doable...

In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture. It has been done before, and seems to work quite well...

In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture. It has been done before, and seems to work quite well...

Certainly, and I've been in both kinds - but that doesn't really solve the question of "if we want programmers that care a bit about the lower-level effects of the code they write, while still being decent at high-level code and structure - what's the optimal order to teach in?"

"In a university context, one might imagine having one course on high-level programming and another on low-level computer architecture."

Don't most students start programming well before they reach university? Even by high school, those who have an interest are probably already programming.

In any case, my university didn't do it that way. All first year courses were taught in Eiffel, a relatively obscure high level language. I'm not even sure we touched C except in specialty electives. After us, they replaced Eiffel with Java in our program, but I doubt they increased emphasis on low level fundamentals.