list of instructions is called a program, and the language that the instructions are written in is called a programming language. To actually write a program you need to learn the language.
And just as there are lots of different natural languages—English, French, Japanese, and so on—there are lots of different programming languages too.
The activities in this section will give you some idea of what it’s like to use a programming language. We can’t teach you one—that would take too long, and it would depend on the computer you had, and all the little details involved might become frustrating and boring. But the really interesting part is not learning the language; that’s routine. The interesting part is having to communicate using a fixed set of instructions that are interpreted literally. And we can show you what that is like.
When you tell people what to do by giving instructions (or they tell you!), they use common sense to interpret what is meant. If someone says “go through that door,” they don’t mean to actually smash through the door—they mean go through the doorway, if necessary opening the door first! Computers are different. Indeed, when they are attached to mobile robots you need to be careful to take safety precautions to avoid them causing damage and danger by interpreting instructions literally—by trying to go through doors. Dealing with something that obeys instructions exactly, without “thinking,” takes some getting used to. That’s what these activities are about.
For teachers
Programming is the very essence of computing, and writing instructions for machines is the essence of programming. The two activities in this section convey a feeling for what it is like to communicate to literal-minded machines using a fixed set of instructions. Both are suitable for middle elementary children and up. Both are group activities that can be undertaken in the classroom, or even (in the case of the first activity and part of the second) outside. There are no special prerequisites, and they can be tackled in any order.
The first activity, in the guise of a treasure hunt, introduces the idea of states and tran-sitions between states that is fundamental to the operation of a computer. A few people giving directions act as the states, and the children must build up a map of how the overall
“machine” works. The second illustrates the difficulty of giving instructions in a form that can be interpreted literally, particularly without the ready feedback and non-verbal cues that we take for granted in interpersonal communication.
Activity 11 is about something that is technically known by the rather forbidding term of finite-state automaton. In ordinary language, an automaton is a self-operating machine, one that works spontaneously. “Finite-state” means that the number of states the machine can be in is not infinite. With these definitions in mind the term “finite-state automaton”
smacks of technical mumbo-jumbo. All machines have a finite number of states—how could it be infinite?—What does it mean to work “spontaneously”? And indeed, this is a case where taking the term apart and looking at its component words doesn’t really help understanding. In computer science, a finite-state automaton is an important abstraction
this book—they are the bane of modern technical writing!—in this case we revert to the commonly-used abbreviation “FSA” because it is no less informative than the phrase it stands for.
We also introduce the acronym RISC for “reduced instruction-set computer,” which is explained in Activity 12. Like many others, this acronym is used, or rather misused, in adjectival form, in phrases like “RISC computer.” ‘ Similar misuse occurs in everyday speech, For example, everyone talks about “PIN numbers” even though the letters stand for “personal identification number,” and New Zealanders invariably refer to “Lake Ro-torua” despite the fact that in the Maori language roto means lake and so Lake Rotorua is redundant.
So don’t worry about the technical terms. The ideas that they describe are simple, and you can use the jargon to impress people!
For the technically-minded
The art of programming is something about which computer scientists wax lyrical. Fred Brooks, a renowned programming manager in IBM during its heyday in the 1950s and 60s when it seemed to be an eternal, invincible force in computing, extolled. . .
. . . the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Although you may be astounded to find a technical subject described in such poetic terms, any programmer will confirm that these words do indeed accurately reflect the joys of their craft (on a good day).
We cannot hope in this book to convey to children the joy of programming, to let them experience first-hand the ecstasy (and the agony!) of creating things that never were nor could be. Instead, we try merely to communicate the notion of instructions as things that are taken very literally. A wider view of the programmer’s craft—the tractability of the medium, the feeling that the only limits to complexity are imposed by one’s own mind, the sheer joy of making things that work—these are the kind of things that com-puter professionals who are visiting a classroom may be able to describe from their own experience.