page 5
I completely agree with the authors that writing real programs, and soon, is the best way to learn programming. This way, concepts which would otherwise seem abstract make sense, and the positive feedback you get from getting even a small program to work gives you a great incentive to improve it or write the next one.
Diving in with ``real'' programs right away has another advantage, if only pragmatic: if you're using a conventional compiler, you can't run a fragment of a program and see what it does; nothing will run until you have a complete (if tiny or trivial) program. You can't learn everything you'd need to write a complete program all at once, so you'll have to take some things ``on faith'' and parrot them in your first programs before you begin to understand them. (You can't learn to program just one expression or statement at a time any more than you can learn to speak a foreign language one word at a time. If all you know is a handful of words, you can't actually say anything: you also need to know something about the language's word order and grammar and sentence structure and declension of articles and verbs.)
The authors list a few drawbacks of this ``dive in and program'' approach, and I must add one more. It's a small step from learning-by-doing to learning-by-trial-and-error, and when you learn programming by trial-and-error, you can very easily learn many errors. When you're not sure whether something will work, or you're not even sure what you could use that might work, and you try something, and it does work, you do not have any guarantee that what you tried worked for the right reason. You might just have ``learned'' something that works only by accident or only on your compiler, and it may be very hard to un-learn it later, when it stops working. (Also, if what you tried didn't work, it may have been due to a bug in the compiler, such that it should have worked.)
Therefore, whenever you're not sure of something, be very careful before you go off and try it ``just to see if it will work.'' Of course, you can never be absolutely sure that something is going to work before you try it, otherwise we'd never have to try things. But you should have an expectation that something is going to work before you try it, and if you can't predict how to do something or whether something would work and find yourself having to determine it experimentally, make a note in your mind that whatever you've just learned (based on the outcome of the experiment) is suspect.
section 1.2: Variables and Arithmetic Expressions
section 1.3: The For Statement
section 1.4: Symbolic Constants
section 1.5: Character Input and Output
section 1.5.2: Character Counting
section 1.8: Arguments--Call by Value
section 1.10: External Variables and Scope
Read sequentially: prev next up top
This page by Steve Summit // Copyright 1995, 1996 // mail feedback