will turn an extra five times. This is a harmless but wasteful solution.
A better approach is to add some type of “loop and test” statement to the Tire-Changing Language:
1. Grab wrench.
2. If lug nut is present
3. {
4. Move wrench to lug nut.
5. While (lug nut attached to car)
6. {
7. Turn wrench counterclockwise one turn.
8. }
9. }
10. Move wrench to toolbox.
11. Release wrench.
Here the program flows from Step 1 through Step 4 just as before. In Step 5, however, the processor must make a decision: Is the lug nut attached? On the first pass, assume that the answer is yes so the processor will execute Step 7 and turn the wrench counter-clockwise one turn. At this point, the program returns to Step 5 and repeats the test. If the lug nut is still attached, the processor repeats Step 7 before returning to Step 5 again. Eventually, the lug nut will come loose and the condition in Step 5 will return a false. At this point, control within the program will pass to Step 9, and the program will continue as before.
This solution is superior to its predecessor: It makes no assumptions about the number of turns required to remove a lug nut. It doesn’t waste effort by requiring the processor to turn a lug nut that is no longer attached, nor does it fail by leaving a lug nut only half-removed.
As nice as this solution is, however, it still has a problem: It removes only a single lug nut. Most medium-size cars have five nuts on each wheel. We could repeat Steps 2 through 9 five times, once for each lug nut. However, this doesn’t work very well either. Most compact cars have only four lug nuts, and large pickups have up to eight.
The following program expands our grammar to include the ability to loop across lug nuts. This program works irrespective of the number of lug nuts on the wheel:
1. Grab wrench.
2. For each lug bolt on wheel
3. {
4. If lug nut is present
5. {
6. Move wrench to lug nut.
7. While (lug nut attached to car)
8. {
9. Turn wrench counterclockwise one turn.
10. }
11. }
12. }
13. Move wrench to toolbox.
14. Release wrench.
This program begins just as before with the grabbing of a wrench from the toolbox. Beginning with Step 2, however, the program loops through Step 12 for each lug-nut bolt on the wheel.
Notice how Steps 7 through 10 are still repeated for each bolt. This is known as a nested loop. Steps 7 through 10 are called the inner loop; Steps 2 through 12 are the outer loop.
The complete program consists of the addition of similar implementations of each step in the algorithm.
Removing the wheel from a car seems like such a simple task, and yet it takes 11 instructions in a language designed specifically for tire changing just to get the lug nuts off. Once completed, this program is likely to include over 60 or 70 steps with numerous loops. Even more steps are needed if you add logic to check for error conditions like stripped or missing lug nuts.
Think of how many instructions have to be executed just to do something as mundane as moving a window about on the display screen (remember that a typical screen may have 1280 x 1024 or a little over a million pixels or more displayed). Fortunately, though stupid, a computer processor is very fast. For example, the processor that’s in your PC can likely execute several billion instructions per second. The instructions in your generic processor don’t do very much – it takes several instructions just to move one pixel – but when you can rip through a billion or so at a time, scrolling a mere million pixels becomes child’s play.
The computer will not do anything that it hasn’t already been programmed for. The creation of a Tire-Changing Language was not enough to replace my flat tire – someone had to write the program instructions to map out, step by step, what the computer will do. And writing a real-world program designed to handle all the special conditions that can arise is not an easy task. Writing an industrial-strength program is probably the most challenging enterprise you can undertake.
So the question becomes: “Why bother?” Because once the computer is properly programmed, it can perform the required function repeatedly, tirelessly, and usually at a greater speed than is possible under human control.
The Tire-Changing Language isn’t a real computer language, of course. Real computers don’t have machine instructions like grab or turn. Worse yet, computers “think” by using a series of ones and zeros. Each internal command is nothing more than a sequence of binary numbers. Real computers have instructions like 01011101, which might add 1 to a number contained in a special-purpose register. As difficult as programming in TCL might be, programming by writing long strings of numbers is even harder.
<main+0>: 01010101 10001001 11100101 10000011 11100100 11110000 10000011 11101100
<main+8>: 00100000 11101000 00011010 01000000 00000000 00000000 11000111 01000100
<main+16>:00100100 00000100 00100100 01110000 01000111 00000000 11000111 00000100
<main+24>:00100100 10000000 01011111 01000111 00000000 11101000 10100110 10001100
<main+32>:00000110 00000000 10001101 01000100 00100100 00010100 10001001 01000100
Fortunately, no one writes programs in machine language anymore. Very early on, someone figured out that it’s much easier for a human to understand ADD 1,REG1 as “add 1 to the value contained in register 1,” rather than 01011101. In the “post-machine-language era,” the programmer wrote her programs in this so-called assembly language and then submitted it to a program called an assembler that converted each of these instructions into its machine-language equivalent.
The programs that people write are known as source code because they are the source of all evil – just kidding – actually it’s because they are the source of the program. The ones and zeros that the computer actually executes are called object code because they are the object of so much frustration.
