| TITLE PAGE | TABLE OF CONTENTS | BIBLIOGRAPHY | AUTHOR'S HOME PAGE |
Another children's book, Computers: How They Work by Nigel Hawkes, points out both the hazards of using metaphors badly and the advantages of using them well. One chapter entitled "The Parts of a Computer" uses the diagram of a desktop as a model for the processes that occur within the computer; the diagram shows several of the structures which are hidden to the naked eye and assigns them metaphorical correspondents. The metaphors aren't all bad - the desktop is one that has certainly been used often - so it took me a while to recognize that several of the objects on the desktop didn't belong in an office. On this particular desktop we find a digital clock (controlling the speed of processing), a bound book (representing ROM) and a notebook (representing RAM). So far so good - all of these objects could very well be found on a desktop. But there are also free floating arrows going to and from the desktop (input/output) and function symbols (+ - x / =) sitting inside a box to represent the processing unit - why they couldn't have used a calculator is unclear - at least that would have made sense sitting on a desk. Finally there is a very odd piece of office furniture indeed: a traffic light. A small traffic light, meant to symbolize the control unit (part of the processing unit), has apparently been bolted to a corner of the desk so that it can control the flow of data from storage to the processing unit and elsewhere. Hawkes' use of the desktop metaphor is somewhat haphazard but in another chapter of this book called "Inside the computer" he presents an effective analogy to describe computer circuitry; he suggests that complex computer circuits look rather like city streets as seen from above:
Each `street' is a wire along which the pulses of electric current flow. The flow of the pulses is controlled by tiny switches, rather as the traffic of a city is controlled by traffic lights... Some [traffic lights] stop the pulses from traveling further through the circuit, others let it pass onward (Hawkes 1983, 16).
Computers, by Neil Ardley, convincingly explains the practicality of memory addresses by analogy, "If information was not labeled in this way the CPU would have to `read' each piece of information stored in its mainstore one by one. It would be like finding someone's telephone number by starting at the first name in the telephone directory and reading through it until you came to the name you wanted" (Ardley 1983, 18).
The metaphor used by computer scientist David Harel - one which applies surprisingly well - is software as recipe: "The ingredients are the inputs to the process, the cake is its output and the recipe is the algorithm" (Harel 1989, 4). Since the recipe is the software, the utensils, oven and, in this case, the baker can be considered hardware. The formal written recipe, the one which appears in the cookbook is analogous to a computer program. Harel's prototype for an algorithm is a recipe for chocolate mousse. The recipe is straightforward; it begins "melt chocolate and 2 tablespoons water in double boiler" and ends with "serve with whipped cream, if desired. makes 6 to 8 servings." This, he writes, is the software relevant to the preparation of the mousse - this is the algorithm that controls the process of producing mousse from the ingredients. Further in the chapter he emphasizes that the input must be legal relative to the purpose of the algorithm; for example, peanut butter and jelly would not be acceptable inputs for the mouse recipe. Harel tackles the confusing subject of how hardware and software are related by using the same metaphor: why does the recipe simply say "stir in powdered sugar;" why doesn't it, for example, specify "take 2,365 grains of powdered sugar, pour them into the melted chocolate, pick up a spoon and use circular movements ... "? The obvious answer is that the baker knows how to stir powdered sugar into melted chocolate and doesn't require more detailed instructions. What if the baker already knew how to make a sugar, chocolate, butter mixture? Then the entire first part of the recipe could be replaced by the line: prepare chocolate mixture. And what if the baker were extremely knowledgeable and knew how to prepare an entire chocolate mousse from memory? Then the entire recipe could be replaced by the single line of instruction: prepare chocolate mouse - in that case the one line recipe is guaranteed to produce the desired output (Harel 1992, 11). Now, consider that the baker is meant to be an element of hardware in this model; Harel has just illustrated that the instructions must be tailored to fit the hardware's particular capabilities. Harel also gives a similar procedural example that relates to computation: when we are asked to multiply two numbers, say 528 by 46 we begin by multiplying the 8 by the 6. Why do this digit by digit? Why not look up the answer in a table, or why not add 6 to itself 8 times? "We assume that the relevant hardware (in this case, we ourselves) is capable of carrying out 8 times 6 but not 528 times 46, and that we can do so in our heads" (Harel 1992, 12).
A curriculum, designed by David Perkins and Steve Schwartz for the Educational Technology Center at the Harvard Graduate School of Education, used the unusual metaphor of the computer as factory. The course consisted of about a dozen lessons and used the image of the "data factory," a conceptual map of the computer, as a programming environment. The data factory is
a place for programs to be stored, a scratch pad for doing arithmetic, a memory area, a keyboard area for input, a screen area for output, and other features. In the data factory lives a worker called NAB. It's NAB who gets things done. Students are encouraged to tell the story of the execution of a program in terms of actions taken by NAB... Telling the story this way gives learners a way of envisioning what the computer does. Moreover, we also developed a computer animation in which students actually see NAB running around the data factory, undertaking such jobs (Perkins 1992, 197).
The acronym NAB is meant to stand for "Not awfully Bright" reinforcing the idea that the computer knows nothing and can do nothing without instructions.
When the considerable task of explaining how computers work to a non-technical audience was attempted by physicist Richard Feynman, he too relied on metaphors to reach his audience. Feynman explained that the computer is nothing but a very fast filing system. First he asked the audience to consider how the system would work if it were just like an old style filing system where all the facts were on index cards. Then he described improvements to the system; the improvements were always to hire a new clerk who is faster but stupider than the previous clerk. Finally we are left with a very fast clerk who can only distinguish between two symbols (or two colors, or high and low). This process will always work as long as there is a precise procedure that can be followed. "The key of it all" says Feynman, "is dumber but faster... ever increasing speed of the file clerk but ever stupider file clerks." He also suggests how we could build a hydraulic computer using high and low water pressure instead of high and low voltages. In this water computer valves and water pipes are arranged so that valves are operated by differences in water pressure. It is interesting how few people use the water pressure and valve model to describe logic gates since the model is often used to describe the behavior of electrical circuits[4]. In this model the valve is an analog for a transistor and water pressure represents electrical current. Feynman concludes that we can make the system simple enough so that we no longer even need a clerk - a machine can do his work. The final suggestion he makes for how to improve the filing system is to get another clerk; or lots of other clerks, this introduces the concept of distributed processing.
In describing the workings of the computer, MIT computer scientist Joseph Weizenbaum used a variety of analogies - perhaps too many and too varied - but each by itself is enlightening. One analogy is a telephone network connecting television subscribers who shout "zero" or "one" into the telephone at the commercial break. He compares logic gates to devices set between these phones which compose a single signal (one or zero) from the many possible incoming signals. Other suggested metaphors are a large train set with two little lights in each station (to illustrate flip flops), mailboxes in a large apartment house (to explain memory addressing) and librarians who farm out the work of retrieving volumes (to demonstrate procedural rules for calling subroutines within a program). While these elaborate metaphors are helpful there isn't one that covers all parts of the computer those who want to understand how computers work are lost in the details of data encoding, binary mathematics and electronic circuitry - each a vast field in and of itself.
Learning to use artifacts correctly isn't always intuitive for student in a field. Graphics are a favorite method of presenting difficult and complex information but graphics can sometimes influence novices too much. Although graphics may benefit from a "gestalt" response (an informative impression of the whole that provides insight into the structure), research demonstrates that when graphics are used by novices to help them learn digital electronics, there can be a failure to abstract from the diagrams. The result is that diagrams are taken literally: the circuit layouts of novices "often reflect the eventual physical layout rather than the logical layout. In effect, they draw a picture of the artifact, rather than depict the structure of the solution" (Petre 1995, 41). In other words, students will interpret a logic diagram of electronics to mean that the circuit should lay out in a similar pattern even if that isn't the best layout. Even so, Petre argues that the sheer likability of graphics and diagrams should not be underestimated; it can be a compelling motivator, and, she notes, graphics are "perceived" as easier to understand.
One of the paradoxes of relying on artifacts, according to Howard Gardner, is that it leads to the devaluation of certain types of intelligences and the destruction of certain important linguistic capacities. But, as Gardner points out, this devaluation is not only a modern phenomenon: Socrates warned that this would be a consequence of writing:
... this invention of yours will produce forgetfulness in the minds of those who learn it, by causing them to neglect their memory inasmuch as, from the confidence in writing they will recollect by the external aid of foreign symbols and not by the internal use of their own faculty (Gardner 1993, 365).
Similarly, the invention of various technological aids may, paradoxically, leave an individual less well prepared to rely on his own abilities. As with media paradigms, cognitive artifacts may force their metaphor on subsequent artifacts. For example, filing cabinets, which were introduced in the early 1900's, represented a revolution in information handling and organization; today this filing system persists as a metaphor which dominates the computer interface.
As early as 1983 researchers at Bank Street College recognized that children were having practical problems as a result of their difficulties in understanding how computers work. Their report recommended that steps be taken in the development of future software to minimize these effects:
Good software must be sensitive to the users' theories of how the computer and its associated parts function and interact. For example, students often get confused about where the program and their text is stored at any given moment. The distinctions between the computer's volatile RAM memory, virtual, disk memory, and permanent disk memory are hard to grasp (Kurland 1983, 12).
Such recommendations suggest that errors in the computational domain may be minimized through the design of interfaces that promote development of accurate naive theories of computation.
Metaphor is a cognitive tool used by interface designers to relate abstract processes to pre-existing mental models. Sometimes, however, an interface metaphor suggests a model that can cause difficulties for users. For example, the Macintosh and Windows operating systems depict screen icons of folders and documents but this has less to do with the way computers work than the way analog filing systems are constructed. This divergence leads to confusion when the computer behaves in a way that is entirely different from the way a filing cabinet works. In the analog world two documents with the same title can peacefully co-exist within the same file folder; however, these two files cannot exist in the same directory of the computer's storage system - the second file placed in the directory will obliterate the first one. "To the extent that an interface metaphor provides users with realistic expectations about what will happen, it enhances the utility of the system" writes Thomas D. Erickson in his essay Working with Interface Metaphors, "To the extent it leads users astray, or simply leads them nowhere, it fails" (Erickson 1990, 73). In evaluating potential interface metaphors he recommends that designers ask: how much is relevant to the problem? Are there any irrelevancies that would lead the user in the wrong direction? Is the metaphor easy to represent? And finally, will the audience understand the metaphor?
At NYU, Shimon Schocken is developing a program in which the software itself is to be a metaphor for a computer. The program, VIC, uses animation and multimedia to introduce fundamental concepts underlying the design of hardware, software, programming and operating systems. Schocken describes VIC as a visual metaphor for the computer but the plain graphics of the interface deliver no information by metaphor - it is unlike anything we are familiar with. On the one hand this is a safe way of developing an accurate model without the risk of using existing metaphors that do not map correctly onto the computer. On the other hand it deprives the student of using existing knowledge and forces the more difficult construction of a mental model from scratch.
If a machine is to serve one very specialized role, such as providing mechanical power, it ought to be hidden and of no concern. But if the purpose of the machine is flexibility and personal adaptability, we had better figure out how to give users maximum control. Expressive power and nuance are incompatible with invisibility and inaccessibility (diSessa 1986, 126).
M.I.T. professor Seymour Papert concurs with diSessa on the benefits of learning to program. Papert is specifically concerned with the cognitive benefits for children. He proposes that programming is nothing more than communicating with the computer in a language that both humans and computers can understand; moreover, since learning language is one the things that children do best, he contends that there is reason to believe they can become proficient programmers if the tools are geared properly for their cognitive abilities. This is the premise behind the creation of the LOGO programming language. Papert believes that it is possible to design computers so that learning to communicate with them would be a natural process, more like learning French by living in France than like learning French in an American classroom. Papert proposed a discovery-based approach for teaching computer programming to children.
Many elementary school students have been exposed to programming concepts through the LOGO programming language. The language is designed so that students can control the learning environment themselves with the expectation that children will discover things on their own. Papert found that with the availability of a computer and LOGO children were capable of solving complex problems in physics, geometry and physiology. (Papert 1980) In the "Forward" to Mindstorms, Papert described his experience with gears as a child to explain why both the experience of discovery and the act of creating mental models are critical for him. Papert credits early play with gears with enabling him to readily learn elementary algebra - he suggests that he was able to plug these abstract concepts into the model provided by the gears. Papert's creation of LOGO was meant to enable children to form models of logical reasoning that would serve as foundations for mathematical concepts. LOGO was Papert's attempt to apply his experience with gears to a wider area of learning. In a paper delivered to the Society for Applied Learning Technology, educational policy analyst Andrew Molnar suggested that LOGO programming is important because "The power of the computer eliminates many manual skills that are prerequisite to mastery and provides a powerful general problem-solving tool that permits students to cope with problems of complexity" (Molnar 1986, 54). He believes that the elementary school curriculum underestimates the capacity of children to solve complex problems and that problem solving skills are introduced at a point so late in the curriculum that most children lose interest or become so dependent on guidance that they never master these skills.
Regardless of the possible cognitive benefits programming may engender in children there is, of course, a need for at least some students to learn programming from a practical standpoint. A recent article on the subject of programming instruction, Using Problem Solving to Teach a Programming Language, advocated an approach to the subject which emphasizes problem solving over the detailed examination of one programming language. The problem solving approach places emphasis on the problem to be solved and the logical steps required for its solution rather than the syntax of a specific programming language. The approach outlined by teacher George Milbrandt in this article suggests the use of "pseudocode" - a rough description of the instructions required - rather than the specific programming code for the first stages of composing a program. Such an approach emphasizes the structure and function of the code rather than specific syntax.
The study of computer science is related to writing programs in somewhat the same way that the study of music is related to the production of songs. The product is important, but the study of the principles behind the product is vastly more so: It is nearly impossible to produce the product without some understanding of the principles (Decker 1990, xvi).
In response to these deficiencies, Decker and Hirschfield set out to design a true survey course. The course introduces a functioning program written in Hypercard; this program is then dissected to determine how it functions. For each level of detail examined there is a corresponding software module that demonstrates the computer processes at that level.
The Journey Inside is a classroom kit and teacher's guide prepared by the Intel corporation which outlines methods that can be used to teach students about computers. The kit contains:
Another part of the program, an IMAX film, is now showing in IMAX theatres in the US.
Intel divides the course into six units: 1. An introduction to computers 2. Microprocessors 3. Digital information 4. Transistors 5. Fabrication facts 6. Critical thresholds. Their focus, not surprisingly, is on the microprocessor with an emphasis on hardware. The instructional approach is described as one that encourages students to build appropriate mental models of how computer hardware functions. The program tries to integrate "hands-on" science in an effort to do this. For example, the programming activity suggests that students write instructions on how to make a peanut butter and jelly sandwich. The teacher is then to try and follow these directions as a demonstration of how the program would be executed. This process demonstrates to students how the smallest error on the part of the programmer can lead to unexpected and incorrect results.
To explain the processing steps in a microprocessor's instruction cycle, Intel suggests a role playing game. In their game, four volunteers are given the roles of Memory, Fetch, Decode and Execute. The class feeds instructions through Memory, Fetch and Decode to program "Execute" who is, effectively, a robot. Memory contains the set of instructions; Fetch goes to Memory and gets one instruction then carries it to Decode. Decode reads the instruction out loud to Execute. Execute (the robot) follows the instructions exactly as written(Intel 1994, 96). This role-playing approach is similar to the teaching method used by Michael Noll, instructor of the "Interactive Telecommunications Technology" course taught at NYU's Interactive Telecommunications Program. Unfortunately, Intel's instructional plan never makes a connection between the programming and logic lesson plans and the units on electricity, circuits and microchip fabrication.
The Boston Computer Museum contains static displays, interactive kiosks and a walk-through scale model of a personal computer. Near the enormous trackball and keyboard there are a few small interactive exhibits. In this area one program called "What is a programming language" exemplifies how a computer game can encourage creation of a mental model. This simple black and white program demonstrates how a small number of bits can be used to encode simple instructions. The program displays a 4X4 grid which is configured to be a slightly different maze for each user. Four switches below the screen are labelled 0 and 1 instead of on and off. The object of the game is to use these four switches to guide the player through the maze; the first two switches are used to give direction (up, down, left, right) and the second two switches are used to indicate distance (the player can move either 0,1,2 or 3 boxes - encoded as their binary equivalents). Simple rules are listed above the screen. Unfortunately, due to the placement of this exhibit in the space, or perhaps because it uses only black and white graphics, this program does not attract much attention. Just beyond the walk-through computer, a grouping of color Macintosh computers on a round table receives far more traffic. A program on one of these machines asks the user to "dig deeper." This program uses a top down approach to explain how the CPU works - it begins with a user's point of view and moves toward an engineering view of hardware. At each stage of the presentation users are asked if they'd like to dig deeper and see more detail. At the deepest level of detail, a photograph of a microprocessor taken through an electron microscope is used as the background. The white pulses in this background are high voltage areas, grey areas are low voltage areas; colorful graphics overlay the gray and white to demonstrate how logic gates can work to calculate digital numbers.
It was interesting to me that critical reading of children's books on the subject of computers revealed that most are difficult to follow and some are inaccurate. A similarity I noted in just about all the children's books is that computers are generally discussed in the realm of computational devices - they are introduced as number crunchers. Little effort is made to demonstrate how bit manipulation can be used to change a color rather than a number, for example. Another similarity among books was that just about every one presents a schematic diagram of the whole computer system; these diagrams use arrows and boxes to describe how structures within the computer work together but they never really make much sense. The one thing that might have helped these diagrams is animation, yet none of the animated programs I've seen has specifically tried to animate a system schematic.
One oddity I discovered was that very little has been published for children since the early 1980s. Most of the children's books seem to have been released around 1983 and 1984; very little appeared later. This ten year gap between most publication dates and the current date only adds to the confusion because some aspects of computing have changed tremendously in the past ten years. These changes can make a difficult subject even more confusing. I can only conjecture as to why such a lapse has occurred: authors may feel that the market was saturated in the early 80s. Or possibly they fear publishing in a field that changes so rapidly - a book could be almost instantly obsolete. Perhaps computers have become so user friendly that children are no longer curious about their inner workings. Or, more likely, once an understanding of how computers work was no longer necessary for productivity, that is, once the interfaces were sufficiently user friendly, the books too were considered unnecessary.
Where authors have tried to use specific programs or computers to illustrate a point (e.g., Computers by Paul Zomberg) their examples appear hopelessly out of date. This problem effectively demonstrates why trying to include information beyond the basics of digital processing can be troublesome. Programs, operating systems and hardware change quickly in this field - only the basic functions of the CPU seem to have remained a constant. In The Analytical Engine, Decker and Hirshfield describe a problem they see as the confusion of training with education; this confusion leads schools to provide excellent training in technologies that will be out of date by the time the students graduate. These are cases where students are taught how to use a particular software package rather than general rules of computer use.
Until the advent of the computer, huge hierarchical problem-solving systems always had to depend on people to carry out the designs of the master strategists. People, unlike computers, are not altogether reliable executors of even the most explicit instructions. The computer programmer's sense of power derives largely from his conviction that his instructions will be obeyed unconditionally and that, given his ability to build arbitrarily large program structures, there is no limit to at least the size of the problems he can solve (Weizenbaum 1976, 105).
In Weizenbaum's view this was not an exclusively positive development; investing computers with such power has a downside too. Weizenbaum is concerned that this ability places too much confidence in the decision making of programmers and those who direct them; too much power can be exercised with a simple flip of a switch. Weizenbaum took great pains to explain what computers are capable of, what they're incapable of and what kinds of things were inappropriate for them to do; he pushed for limits on the kinds of tasks that computers would be entrusted with. At the Boston Computer Museum, in the "Smart Machines" area, I overheard a parent reading copy from one of the header panels to his family: "What is the difference between humans and Smart Machines?" the exhibit asked. In response, a child of about 5 or 6 yelled a response: "Nothing!" I mention this anecdote to stress that children who do not understand how computers work and the function of programming tend to overestimate computer power (Mawby et al. 1984). The ability to determine which tasks are appropriate for computers does not develop without a general understanding of what computers do.
If we wish our students to become intelligent consumers rather than naive users of computer technology, we must teach them something beyond the use of off-the-shelf packages. To participate knowledgeably in shaping future technology and public policies, people need a basic understanding of how computers work (Schocken, 1994).
In Computers Neil Ardley provides an even simpler rationale for learning the "irrelevant" details of computer science:
An understanding of how everything works in a computer, from the translation of instructions and data into binary code and the handling of information through electronic switches, to the processing of information though the answering of yes/no questions, will help you to understand how to "talk" to a computer, for these are the terms in which it will "understand" and cope with the tasks you want it to carry out (Ardley 1983, 73).
Or to use a metaphor of my own design, if you arrive in a foreign country and know very little of the language, it will be helpful to know something of the local culture - the basic rules and customs that you will be expected to honor. The same general recommendation can be made for those who plan to navigate new programs and unfamiliar interfaces; a basic understanding of the underlying rules and processes of the computer will assist your navigation.
Copyright © 1996 by Lisa H. Weinberg