✔ Examining things that could go wrong
✔ Visit www.dummies.com for great Dummies content online.
Chapter 1
What Is a Program?
In This Chapter
▶ Understanding programs
▶ Writing your first “program”
▶ Looking at computer languages
In this chapter, you get a handle on what a program is and what it means to write a program. You get to practice on a Human Computer and see some program snippets written for a real computer. Finally, you get a look at your first code snippet written in C++.
Up until now, all of the programs running on your computer were written by someone else. Very soon now, that won’t be true anymore. You’ll be joining the ranks of the few, the proud: the programmers.
A computer is an amazingly fast but incredibly stupid machine. A computer can do anything you tell it (within reason), but it does exactly what it’s told – nothing more and nothing less.
In this respect, a computer is almost the exact opposite of a human: Humans respond intuitively. When I was learning a second language, I found that it wasn’t enough to understand what was being said – it’s just as important and considerably more difficult to understand what was left unsaid. This is information that the speaker shares with the listener through common experience or education – things that don’t need to be said.
For example, I say things to my son such as, “Wash the dishes” (for all the good it does me). Such instructions seem clear enough, but the vast majority of the information contained in that sentence is implied and unspoken.
Let’s assume that my son knows what dishes are and that dirty dishes are normally in the sink. But what about knives and forks? After all, I only said dishes, I didn’t say anything about eating utensils, and don’t even get me started on glassware. And did I mean wash them manually, or is it okay to load them up into the dishwasher to be washed, rinsed, and dried automatically?
But the fact is, “Wash the dishes” is sufficient instruction for my son. He can deconstruct that sentence and combine it with information that we both share, including an extensive working knowledge of dirty dishes, to come up with a meaningful understanding of what I want him to do – whether he does it or not is a different story. I would guess that he can perform all the mental gymnastics necessary to understand that sentence in about the same amount of time that it takes me to say it – about 1 to 2 seconds.
A computer can’t make head nor tail out of a statement as vague as “wash the dishes.” You have to tell the computer exactly what to do with each different type of dish, specify that silverware is included in the task, and state how to wash a fork, versus a spoon, versus a cup. When does the program stop washing a dish (that is, how does it know when a dish is clean)? When does it stop washing (that is, how does it know when the task is finished)?
My son has gobs of memory – it isn’t clear exactly how much memory a normal human has, but it’s boatloads. Unfortunately, human memory is fuzzy. For example, witnesses to crimes are notoriously bad at recalling details, even a short time after the event. Two witnesses to the same event often disagree radically on what transpired.
Computers also have gobs of memory, and that’s very good. Once a fact is stored, a computer can retrieve that fact as often as you like without changing the fact. As expensive as memory was back in the early 1980s, the original IBM PC had only 16K (that’s 16 thousand bytes). This could be expanded to a whopping 64K. Compare this with the 2GB to 6GB of main storage available in most computers today (a gigabyte, 1GB, is one billion bytes).
As expensive as memory was in the early days of personal computing, the IBM PC included extra memory chips and decoding hardware to detect a memory failure. If a memory chip went bad, this circuitry was sure to find the problem and report it before the program went haywire. This so-called parity memory was discontinued after only a few years; as far as I know, it’s unavailable today except in specific applications where extreme reliability is required – because the memory boards almost never fail.
On the other hand, humans are very good at certain types of processing that computers do poorly, if at all. For example, humans are very good at pulling the meaning out of a sentence garbled by large amounts of background noise. By contrast, digital cellphones (which are at least as much computer as phone) have the infuriatingly bad habit of just going silent whenever the noise level gets above a built-in threshold.
The remainder of this chapter looks at instructions that come a little closer to telling the computer to “wash the dishes” (or some equally fuzzy task).
Before I dive into showing you how to write programs for computer consumption, I start by showing you a program to guide human behavior so that you can get a better look at what you’re up against. Writing a program to guide a human is much easier than writing programs for computer hardware. That’s because we human beings have a lot of experience in dealing with each other – which gives us some familiarity with (and understanding of) humans and how they work. (I’ll assume that much, anyway.) We also share a common human language; no need to translate everything into ones and zeroes. But assume that the human computer in this thought experiment takes every instruction quite literally – so the program will have to be very specific.
The problem I’ve chosen is to instruct our human computer how to change a flat tire.
The instructions for changing a flat tire are straightforward and go something like the following:
1. Raise the car.
2. Remove the lug 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.