nuts that affix the faulty tire to the car.
3. Remove the tire.
4. Mount the new tire.
5. Install the lug nuts.
6. Lower the car.
Okay, even these everyday terms are potentially fuzzy: Technically the lug nuts hold the wheel, not the tire, on the car. To keep it simple, assume that the terms “wheel” and “tire” are synonymous, and that the computer understands them as the same thing.
As detailed as these instructions might seem to be, they still don’t make up a program. Such a set of instructions is called an algorithm – a description, usually at a high level of abstraction, of the steps to be performed. An algorithm is detailed but general. I could use this algorithm to repair any flat tire I’ve experienced or ever will experience. But an algorithm does not contain sufficient detail to allow even our intentionally obtuse human computer to perform the task.
Before we can write a program, we need a language that we can all agree on. For the remainder of this book, that language is C++, but for this example, I use an imaginary language: TCL (Tire-Changing Language). I have specifically adapted TCL to the problem of changing tires.
TCL includes a few nouns common in the tire-changing world:
✔ car
✔ tire
✔ nut
✔ jack
✔ toolbox
✔ spare tire
✔ wrench
TCL also includes the following verbs:
✔ grab
✔ move
✔ release
✔ turn
Finally, the TCL-executing processor will need the ability to count and to make simple decisions. Finally, the TCL processor knows directions like up vs. down, left vs. right and clockwise vs. counter-clockwise.
These words in TCL are all that the tire-changing robot (the imaginary human computer) understands. Any other command that’s not part of Tire-Changing Language generates a blank stare of incomprehension from the human tire-changing processor.
Now it’s time to convert the algorithm, written in everyday English, into a program written in Tire-Changing Language. It’s not as easy as it might seem. Take, for example, the phrase, “Remove the lug nuts.” Actually, quite a bit is left unstated in that sentence. The word remove is not in the processor’s vocabulary. In addition, a wrench (which is a word the computer knows) is never mentioned in that phrase, though we all know that a wrench must be involved. We can’t assume that the computer knows what we know.
(If you haven’t changed a flat tire – and didn’t know that a wrench is required to remove lug nuts, or what a lug nut is – then just play along for now. You’ll figure it out.)
The following steps implement the phrase “Remove a lug nut” using only the verbs and nouns contained in Tire-Changing Language:
1. Grab wrench.
2. Move wrench to lug nut.
3. Turn wrench counterclockwise five times.
4. Move wrench to toolbox.
5. Release wrench.
At this point, consider these aspects of the syntax (required word order) implied in this example of Tire-Changing Language:
✔ Every command starts with a single verb.
✔ The verb grab requires a single noun as its object.
✔ The verb turn requires a noun, a direction, and a count of the number of turns to make.
Even so, the program snippet should be easy enough to read (after all, this isn’t a book about Tire-Changing Language).
The program begins at Step 1 and continues through each step in turn until reaching Step 5. In programming terminology, we say that the program flows from Step 1 through Step 5. Of course, the program’s not going anywhere – the processor is doing all the work – but program flow is a common term for this smooth execution of steps.
Even a cursory examination of this program reveals a problem: What if there is no lug nut? I suppose it’s harmless to spin the wrench around a bolt with no nut on it, but doing so wastes time and isn’t my idea of a good solution. The Tire-Changing Language needs a branching capability that allows the program to take one path or another in response to external conditions. We need an IF statement such as the following:
1. Grab wrench.
2. If lug nut is present
3. {
4. Move wrench to lug nut.
5. Turn wrench counterclockwise five times.
6. }
7. Move wrench to toolbox.
8. Release wrench.
The program starts with Step 1 just as before, and grabs a wrench. In the second step, however, before the program waves the wrench uselessly around an empty bolt, it checks to see if a lug nut is present. If so, flow continues with Steps 3, 4, and 5 as before. If not, however, program flow skips these unnecessary steps and goes straight on to Step 7 to return the wrench to the toolbox.
In computerese, you say that the program executes the logical expression “is lug nut present?” This expression returns either a true (yes, the lug nut is present) or a false (no, there is no lug nut there).
I realize that there’s no need to grab a wrench if there’s no lug nut to remove, but work with me here.
This improved program still has a problem: How do you know that five turns of the wrench will be sufficient to remove the lug nut? It most certainly will not be enough for most of the tires with which I am familiar. You could increase the number of turns to something that seems likely to be more than enough, say, 25 turns. If the lug nut comes
