of these smaller tasks may be, “Identify the lottery numbers that tend to appear often.” A second task may be, “Pick the six numbers that have appeared most often and display those as the potential future winning numbers.”
The idea is that writing a large program may be tough, but writing a small program is easy. So, if you keep dividing the tasks of your program into smaller and smaller parts, eventually you can write a small, simple program that can solve that task. Then you can paste these small programs together like building blocks, and you’ll have a well-organized big program — theoretically.
Now if you need to modify part of the large program, just find the small program that needs changing, modify it, and plug it back into the larger program, and you’ve just updated the larger program.
Ideally, each small program should be small enough to fit on a single sheet of paper or a single screen. This makes each small program easy to read, understand, and modify. When you divide a large program into smaller programs, each small program is a subprogram.
If you divide a program into multiple subprograms, you have two options for where to store your subprograms:
Store all your subprograms in a single file. This option is fine for small programs, but after you start dividing a program into multiple subprograms, trying to cram all your subprograms into a single file is like trying to cram your entire wardrobe into your sock drawer. It’s possible, but it makes finding anything later that much more difficult.
Store subprograms in separate files, as shown in Figure 2-4. Storing subprograms in separate files offers three huge advantages:The fewer subprograms crammed into a single file, the easier it is to find and modify any of them.If you store subprograms in a separate file, you can copy that file (and any subprograms stored in that file) and then plug it into another program. In that way, you can create a library of useful subprograms and reuse them later.By reusing subprograms that you’ve tested already to make sure they work properly, you can write more complicated programs in less time, simply because you’re reusing subprograms and not writing everything from scratch.
FIGURE 2-4: You can store subprograms in one big file or in separate files.
STRUCTURED PROGRAMMING AND PASCAL
You can use structured programming techniques with any programming language, including machine language or assembly language (see Book 1, Chapter 1). However, the one language most closely associated with structured programming is Pascal.
Unlike other languages that later adopted structured programming, Pascal was designed to encourage (force) programmers to use structured programming from the start. A typical Pascal program may look like this:
Program Print2Lines;Begin Writeln ('This line prints first'); Writeln ('This line prints second');End.
Without knowing anything about the Pascal language, you can immediately make sense out of what it does.
First, it prints the line, This line prints first.
Next, it prints the second line, This line prints second.
Unlike the BASIC example that allows spaghetti programming (see “Spaghetti programming with the GOTO command,” earlier in this chapter), Pascal forces programmers to structure programs using sequences, branches, and loops. As a result, Pascal helps programmers create well-organized programs that are much easier to read and understand.
Event-Driven Programming
In the early days, using a program was fairly simple. After you typed the command to run a particular program, that program might ask a question such as
What is your name?
At this point, you had no choice but to type a name, such as Charlie Smith. After you typed in your name, the program might respond with
Hello, Charlie Smith. What month were you born?
The moment you typed in a month, such as April, the program might respond:
What day were you born?
And so on. If you wanted to type your day of birth before your month of birth, you couldn't because the program controlled your options.
Not surprisingly, using a computer like this was frustrating to most people, so computer scientists soon invented something called a graphical user interface (GUI). A GUI displays multiple options to the user in the form of drop-down lists, windows, buttons, and check boxes. Suddenly, instead of the computer dictating what the user could do at any given time, the user could tell the computer what to do at any given time, just by choosing one of many available commands.
Forcing each program to display menus and windows had two advantages for users:
It made using a computer much easier. Instead of having to type in commands, users could just click the command they wanted to use.
It’s fairly easy to figure out how to use different types of programs. After you understand that you can choose the Print command from the File menu, you know how to print in any program — whether it’s a word processor, a database, or an image-editing program.
Unfortunately, although drop-down lists made programs easy for users, they made writing programs much harder for programmers:
Programmers had to write extra commands just to display all these fancy drop-down lists and windows. (Even worse, programmers had to make sure all those extra commands used to create drop-down lists and windows actually worked correctly.)
Programmers now had to write programs that could react to whatever command the user chose. Instead of presenting the user with options in a specific, predictable order, programs had to handle the unpredictable choices of the user.
To solve this dual problem of creating drop-down lists and knowing how to handle the different commands the user may choose at any given time, computer scientists developed event-driven programming.
In event-driven programming, an event is something that the user does or that the computer must respond to. The user might click a drop-down list or click a button displayed in a window. The computer might need to respond to an incoming email or a file being added to a directory. Event-driven programming simply focuses on displaying different commands onscreen and then handling these different events when they occur.
Event-driven programming divides programming into three distinct parts:
The user interface (UI): The commands the user sees onscreen
The event handler: The part of the program that reacts to the commands the user chooses from the
