I learned C by reading K and R and doing the book's exercises . . . on paper. At the time I didn't have access to a C compiler, so I wrote them all out in a notebook. A month later I got a job at a shop that was running Unix, and got the chance to type my programs in and try them.
I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). But the 30 days I spent without a compiler made me think about program behavior.
I'm not saying this is a great way to learn a language, but it can be done.
I keep hearing people complain about K and R being "a terrible book." For me it was perfect: pragmatic, succinct, with great examples and good exercises.
And that is what anyone who goes through K&R will do: Reading and writing lots of real programs. A simple program is worth a thousand words!
Which unfortunately the majority of technical books just can't get right. Explain the concepts in 5 full dull pages, and then at the end "Hey, checkout this little snippet of code, which by the way does nothing really interesting, but is here to illustrate what the author was talking about :)"
I'd like to add some emphasis on reading. For a beginner, writing is obviously very very important as the way to get to the point where he can just sit down and solve a given task.
But reading lots and lots of code (from many different sources) will help him pick up idioms and find common & good solutions to specific problems. Even for a smart person, I think it'll take a lot of time and effort to arrive to the cleanest way of doing things.
Of course there's a risk of picking up bad habits, but if you read lots of code, you should eventually develop a feel for what's clean and readable and easy to understand, and what's messy and wrong. This sadly doesn't help with issues like undefined behavior, but you don't learn these just by writing either. For that you need to look into the spec or some other text that'll cover these.
EDIT: I like to think that I'm a fairly good C programmer (having coded nearly all my life, with C mostly), but I still peek into others code all the time to find out how they've solved some things I'm about to do.
I'll second this notion. I no longer write C, but it is what I learned in high school. My teacher had an interesting class requirement: we needed to review one C/C++ Users Journal article. Length, difficulty, or topic didn't matter - just read a trade article and write about it. We also had to code a lot, and we had to write code by hand on paper tests, and we had some fun competing, but the journals let me know what the Real World was doing.
It takes a large volume of work to really get into programming, and I think that reading is easier than writing, so it's a fast way to dig in (keeping in mind that feedback is critical - so reading without writing has severe diminishing returns)!
People don't like K&R? I can understand it not being suitable for children and the very beginner, but it's one of a very few programming books that is useful, succinct, pragmatic, doesn't get bogged down in APIs, and is written clearly.
(The companion book "Programming in the UNIX environment" is the get-you-started guide from the very beginning, although it assumes 1970s terminal defaults)
Edit: Most resources on the Internet are too confusing for beginners. As a matter of fact, people who know C are usually unable to teach C to novices. Good introductory resources for C are rare - which corresponds to C's elitist nimbus.
That's great. I learned C by telling people I had C experience then when I got a job offer I was forced to learn it pretty quickly over a weekend powered by coffee and yorkie bars and a pirate copy of Microsoft C. I had plenty of experience with assembly at the time.
fortunately I wandered into a company that had even less of a clue than me. It's nice to be an expert on day one with only two days' of expertise :)
And that may give you a leg up on the rest of us. Not enough thinking of this sort gets done.
In fact, this is how one of the great teachers of CS, Dijkstra, taught computer science.
I have been known to complain about the second edition--the first is the one that I go back to. But it is an absolutely fundamental book for understanding the practicality of programming. I agree with your assessment.
I find the visceral act of manually writing code to be an extremely effective tool when learning programming language syntax. I find it similar to the "Write these words 10 times" technique used when teaching grade school kids how to spell and read.
I guess this is sort of I'm thinking about this, that is forcing people first to think how something should work, rather then just duplicating some code and seeing that it works. Thanks for sharing!
I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). But the 30 days I spent without a compiler made me think about program behavior.
I'm not saying this is a great way to learn a language, but it can be done.
I keep hearing people complain about K and R being "a terrible book." For me it was perfect: pragmatic, succinct, with great examples and good exercises.