the order

If I had to talk someone through learning C that had never been exposed to programming before, I'd probably make them go through something similar to how I grew up (although accelerated over months instead of 15 years).

1) Take an existing program with a graphical element in a non-complied language and modify bits of it. My first experience with a programming language was GW Basic and QBasic. I learned how to write loops to say things like "Chris is the best" over and over again on the screen. You can easily see in the code where the parts are for what is written on the screen, and how many times it loops. After that, I messed around with QBasic's Gorillas and Nibbles demos. It's pretty simple to find where the velocity and other parts are. Changing something that's already there and straightforward to run is an easy instant-gratification thing to do. I don't think that there are modern equivalents to this!

2) Dive into Pascal. This was the second language I got familiar with, and it introduced me to modern syntax, variables, advanced loops and other control elements, reading/writing files, objects, and doing more graphically advanced things on the screen. It's possible to compile Pascal, so that's a good step to learn.

3) Baby steps into C. My first experience with C was either Turbo C++ or DJGPP, I can't remember. I could do almost everything in C that I could do in Pascal except for reading/writing files and doing interesting things on the screen. DJGPP had the Allegro libraries ready to go, but this was where knowing how structures and pointers worked would have been useful. Ultimately I got frustrated and never advanced. So, I wouldn't recommend that path. I'm working on an order of learning for C that would have helped me when I was younger. The problem is the instant gratification element. Getting things on screen these days is difficult now that the console has been marginalized. Making little ASCII art characters walk around is prohibitively difficult - in fact I probably couldn't even do it now! It seemed so trivial in Basic and Pascal in hindsight.

K&R, as I've said before, is a great reference but poor tutorial. Not that it's trying to be one, but still. It really cheesed me off over the weekend with the structure padding thing. Structure padding seems so freaking important of a thing to know, but it gets one lousy sentence in K&R.