
Developing Thinking Skills with Computersby John B. Black, Karen Swan & Daniel L. Schwartz  1988 A study in which Logo programming was used to teach problemsolving skills to fourth to eighth grade students is described. The results, and their implications for further use of the computer to teach higher order thinking skills, are discussed. The possible use of Prolog programming to teach reasoning skills is described. (Source: ERIC) Computers, in and out of education, are powerful retrievers of information. In an age of information, our key need is not to retrieve more of it with yet greater ease, but to reason more astutely. Will working with computers and new logicoriented language; help? A number of recent surveys of students’ skills in the United States have converged on a single, general conclusion: Students have mastered mechanical, lowerlevel skills in a variety of areas, but they are sorely lacking in the ability to do higherorder thinking in these areas. For example, the National Assessment of Educational Progress (NAEP) found that the problems with student writing were not in mechanics but in thinking and organization.1 Another NAEP study found that young adults could read a short newspaper story to find a specific fact, but could not summarize an argument presented in an editorial.2 Yet another NAEP study found that students’ computational skills were fine, but that their problemsolving abilities were weak.3 Thus we must find better ways of teaching higherorder thinking skills to students in all domains, because the current approaches are not working. In this article we argue that computers can be used effectively to convey thinking skills to students.4 Specifically, we describe how to use Logo programming to teach problemsolving skills in a way that will generalize over specific domains, and we discuss how to use Prolog programming to teach generalizable reasoning skills. We also provide a brief discussion of using computers to teach two kinds of reasoning that critics have accused computers of undermining—reasoning with images and reasoning from experience. Before claiming that we are teaching and measuring problemsolving or reasoning skills we should have a clear view of each. Problem solving, for example, is not a single skill.5 Each given problem may require a different skill or combination of skills for its solution. Problemsolving behavior might be viewed as the selection and application of an appropriate strategy for a given problem. At other times, problem solving takes on the character of an “ahha!” when the solution comes to mind after a good sleep. To instruct in problem solving we need to choose an amenable collection of strategies with which to work. Therefore, we have chosen a few specific genres of problem solving to emphasize: subgoal formation, forwardchaining, backwardchaining, systematic trial and error, alternative problem representation, and analogical reasoning. One must also distinguish reasoning from problem solving and suggest the component skills that make up reasoning activity. By making a clear specification of the cognitive skills we plan to teach, both instructional objectives and methods of evaluation become feasible. The notice of a problem space introduced by Newell and Simon6 provides an organizing framework for discussing thinking skills. A problem space is composed of two general conceptual categories: states and operators. A state is a possible state of the world or problem situation (represented by circles in Figure 1). An operator is something that can be selectively applied to a state to change it to another state (represented by letters labeling arrows in Figure 1). For example, if someone is in a state of hunger, then eating something (an operator) may change the state to one of satiation. States and operators should be defined at a level of specificity and emphasis appropriate for the problem. For purposes of human action, the states and operator just described are about the right level. However, if we were trying to program a robot to mimic human eating habits, then we would have to use a much more detailed level of description (e.g., location in living room, go to kitchen, location in kitchen, go to refrigerator, and so forth). The selection of an appropriate level of detail and direction of emphasis is most closely aligned with the problemsolving activity of choosing alternative representations. If one represents the states and operators for solving a problem incorrectly, creating an alternative representation might be more conducive to solution. Experts in physics evidently spend a large proportion of their time correctly representing or formulating the problem state and the applicable operators before attempting to solve a problem. Novices, on the other hand, quickly choose a less appropriate representation of the problem state (generally a familiar equation).7 Given these two elements, states and operators, we can begin to construct a problem space. A problem space can be graphically imagined as an upside down tree. At the top of the tree is the initial state of affairs, for example: Dan is in New York (see Figure 1). At the bottom of the tree is the goal state: Dan is in the Bahamas. In between the initial state and the goal state we find a collection of intermediate states that can be derived by applying the operators to the immediately prior (above) state. From the initial problem state and given our limited set of available operators in the figure, Dan can reasonably apply four operators: Buy a boat ticket; Buy a plane ticket; Go to the airport; Go to the dock. Applying each of these operators yields a new state. Applying appropriate operators to the newly derived states gives us further states, until one (or more) of the newly created states is the goal state. There are two important points to be made. First, the problem space represents all of the possible states that can be derived using the operators. In reality, Dan will not reach all of the states. However, when reasoning about the problem of getting to the Bahamas, Dan should be able to reason out all these possibilities. Second, not all operators can be applied to all states. Dan cannot disembark before he has boarded a vessel. With this introduction to the framework of problem spaces we can use it to make some distinctions between types of problem solving and deductive reasoning. Once one has solved the problem of selecting an initial representation of the problem and choosing the available operators, reasoning comes to the fore. For the current discussion, deductive reasoning is the ability to decide which operators may apply to a particular state and the ability to deduce all of the possible consequences from each operator’s application. Note that this is a somewhat more general conception of reasoning than the usual restriction of reasoning to application to operators from formal logic. Isolating logic problems from others seems artificial, so we will use this more general conception of reasoning.8 From this perspective, reasoning is what enables us to create the problem space. With this ability to create the problem space of possibilities, problemsolving abilities allow us to navigate the space so that we can reach the goal. For example, reasoning says that Dan can go from the dock to the airport, the airport to the dock. Problem solving tells us that this is not likely to be an effective strategy for reaching his goal. A different path through the problem space is more effective. This example of problem spaces does not give one a sense of the power of this formulation for explaining thinking. Let us imagine a more complicated problem space. For example, take the problem of solving the following algebraic expression: Initial State: X +1 = X^{2} + X – 3. Our goal state, or in this case goal states, should give us: Goal States: X = 2 X =  2 What would the problem space in between be like? It is immense. For the first transformations of the initial state we can derive a substantial range of intermediate steps, including nonproductive ones like Intermediate State: X^{2} + X + 1 = X^{2 }+ X^{2 }+ X  3. Reason, as the application of rules to produce legal consequences, allows us to come up with such an expression. Reasoning with the rules of algebra prevents us from creating an expression like Initial State: X +1 > X^{2} + X – 3. Using reason to generate all the possible states from the initial state and then the next intermediate states and so on creates a problem space too large to work with. We cannot keep track of all the possibilities simultaneously. Problem solving, in our usage, helps us choose the most promising path to the solution. Often we choose the wrong path. We might use the first transformation shown above, which leads us away from the goal. Expert problem solvers might choose a second state like An Expert’s First Intermediate State: 1 = X^{2 }– 3, which they know will lead more efficiently to the goal. How do experts know how to move through the problem space in this direction? No doubt a great deal of experience in the domain has taught them that this is a factoring problem that should get into the form of 0 = <expression>. This is an example of subgoal formation. Rather than looking way ahead to the final goal, the problem solvers set up an intermediate goal that they know will facilitate finding the final solution. Another approach might be to follow a particular path mentally for several steps to see if something promising develops. For example, one might follow a path that collects all the Xs on one side. This is an example of forwardchaining. Problem solvers mentally follow a chain of reasoning to see if it leads to a propitious state. If it does they will commit to following this chain and probably begin to take actions according to this line of reasoning (e.g., write down the transformations on paper). If it is not a promising approach, they can try another chain of deductions. Or they might start from the form of the solution to see if they can build a chain of reasoning that will lead them back to the initial state. This is backwardchaining. This is especially effective if one has found the answer in the back of the book. They might create a new initial state X = 2. From this they will perform a series of operations to reach the original problem statement. On the papers to be turned in for grading, our problem solvers can then reverse the sequence of steps to show their proof for the solution. Another approach to the problem might involve “pruning” the problem tree. Through systematic trial and error, problem solvers can exclude whole lines of reasoning early on by recognizing that a toplevel state cannot possibly lead to the desired goal. The last area of problem solving we consider is analogical reasoning. If students had seen several problems like this before, they could analogize that this problem is the same and use the steps that helped in the previous problems. It should be clear that expertise in algebra will considerably aid problem solvers in creating the problem space according to the principles and axioms of algebra. Similarly, domain knowledge of algebra will help problem solvers choose a correct strategy for solving the problem. Nonetheless, the strategies and reasoning skills used are found in all domains. Subgoal formation might be used by Dan to realize that he needs to reach the subgoal of being at the airport with a ticket. The critical question is whether the practice of these problemsolving skills in algebra would show some positive side effects in areas of knowledge like geometry, science, and even English. More to the point, will programming a computer provide a superior medium for the development and extension of these abilities? With a clear demarcation of the general skills, we have good objectives to teach to and a clear eye toward the manifestation these skills will take in other areas of knowledge so that we can teach for transfer. USING LOGO TO TEACH PROBLEM SOLVING Because it uniquely combines concrete, formal, and procedural representations of ideas, computer programming is often prescribed as fertile ground for the teaching and learning of problem solving. The Logo programming language, in particular, was developed for just such a purpose.9 Research to date, however, has failed to clearly identify either the cognitive mechanisms or the pedagogical approaches that cultivate the development of problemsolving skills within programming contexts, let alone the transfer of problemsolving skills from programming to other educational contexts.10 Failure to document the transfer of thinking and problemsolving skills is, of course, not at all new to educational research; it dates from Thorndike’s early debunking of the notion that the study of Latin improves reasoning.11 It would seem that either we have yet to find a way to teach problem solving in our schools, or that we have yet to find a way to measure its transfer from specific to more general academic domains. We will summarize here an initial study investigating the transfer issue in its contemporary programming/problemsolving incarnation.12 We sought a finergrained analysis of the problemsolving strategies involved in Logo programming environments, of the pedagogical approaches that might help cultivate such processes, and of the cognitive mechanisms involved in the transfer of these to noncomputer contexts. Several notions guided our inquiry. To begin with, the teaching and learning of Logo has been notoriously nondirective.13 The long history of failure to discover transfer effects suggests that the transfer of problemsolving skills is hardly automatic. We determined, therefore, to focus attention on the problem solving in programming. We devised introductory, offcomputer activities designed to highlight particular problemsolving techniques, and followed these with sets of programming problems to which such strategies were particularly amenable. At the same time, we tried to remain faithful to the spirit of the educational philosophy espoused by Logo’s creators.14 We made the introductory activities both concrete and syntonic; we followed an openended, projectoriented approach in the problem sets; and we maintained a Socratic, guideddiscovery pedagogy in our interactions with students. Second, we believe that problemsolving abilities are themselves instances of a larger ability to think logically and abstractly, and that this ability, which Piaget terms formal operational,15 develops slowly during the period when a child is in middle and junior high school. We accordingly addressed our research toward children in this age range in an attempt to determine whether and/or when Logo programming/problemsolving experience might be useful. A third consideration involved the generality of the concept of problemsolving abilities. Many authors have decomposed this into a number of distinct skills or strategies.16 Certain such strategies seem more applicable to programming problems in general, children’s programming in particular.17 It seems probable, moreover, that of these, differing strategies become available at differing points in a child’s development.18 We identified six problemsolving strategies that we believed might be useful to children programming computers at some point in their development. These were subgoals formation, forwardchaining, backwardchaining, systematic trial and error, alternative problem representation, and analogical reasoning. In an effort to isolate the particular techniques most relevant in programming domains and/or most available for transfer to problem solving in other domains, we developed our instructional units and our measuring instruments around these six strategies. Another consideration in the development of problemsolving skills involves the metacognitive monitoring of both the abstraction of such skills from particular contexts and their application in new domains.19 There is some reason to believe that the explicit modeling of metacognitive behaviors helps students isolate and assimilate them.20 Our use of introductory activities to highlight the specific strategies being explored and our adherence to a guideddiscovery pedagogy reflect a concern with explicitly invoking metacognitive behaviors. In addition, we devised worksheets for students to fill out, asking them to delineate the problem space by identifying, in words and/or pictures, the givens, goal, and solution steps involved in each problem solution. We hoped that such deliberately forced attention to what Polya calls “understanding the problem”21 would develop a corresponding metacognitive habit. Finally, the teaching and learning of Logo have been, for the most part, restricted to the turtle graphics domain generally associated with the language. Indeed, the major Logoproblem solving studies appear to be based solely on graphics programming.22 The Logo language, however, is far richer than turtle graphics alone would suggest. Logo makes list manipulation accessible to young children.23 Programming with lists invokes a context quite different from graphics, a context more closely representing the workings of the language itself—hence, perhaps, more suited to problem solving within it. Additionally, research by Gick and Holyoak suggests that problem solutions are more easily abstracted and generalized from multiple, as opposed to single, base domains—that the transfer of problem solutions more readily occurs when these are initially encountered in more than one context.24 We thought that students working on problems in both graphics and listmanipulation contexts might be more likely to abstract and apply the problemsolving strategies they were using in new domains. Seeking to distinguish between varying base domains by varying the contexts of the problem sets, we created three student groupings and gave one group solely graphics problems to work on, one group solely listmanipulation problems, and the remaining group both graphics and lists problems. Our subjects were 133 students in the fourth through eighth grades of a private suburban elementary school, all of whom had previous experience with both graphics and lists programming in Logo. They were randomly assigned by grade to one of the three contextual groupings. These remained constant across six instructional units corresponding to the six identified problemsolving strategies. A consistent instructional sequence was followed for each strategy unit. Our experimental design can be conceived, then, as a problemsolving strategies by contextual groupings by grade levels matrix, with context and gradelevel groupings being betweensubjects variables, and strategies, a withinsubjects variable. The dependent variable was pre and posttest scores on six measures of facility with particular problemsolving strategies. Students were introduced to each problemsolving strategy through a wholegroup activity designed to provide a concrete, offcomputer model of the processes involved in it. For example, forwardchaining strategies were introduced with a treasure hunting game in which students followed a sequence of clues to discover a hidden treasure. For backwardchaining, we reversed the game and had student groups create the treasure hunts, an activity that has to be done from the treasure back to the first clue. Concrete strategy activities were followed with noncomputer example problems that were again presented to the whole class. Example problems were classic puzzles, such as the missionaries and the cannibals, the water jugs, and the heavy coin problems (See Table 1). The group work of the introductory exercises was followed by individual or paired work on the problemsolving sets. Students were required to write solutions for three programming problems, all of which were particularly amenable to solutions employing the specific problemsolving strategy currently being explored. The first two core problems varied according to student groupings: Students in the graphics condition were given two problems involving graphics manipulation, students in the lists condition worked on two listmanipulation programs, and students in the twodomain condition had one graphics and one lists problem to solve. The third programming problem in each problem set served as a test of students’ facility with each particular strategy across groupings. These problems were the same for all students and involved arithmetic problems, a third and unfamiliar programming context. Students worked on the problems during two fortyfive minute class periods each week. A teacher and an intern were available for help with all the problems during alternating class periods. Both maintained a guideddiscovery approach toward student assistance, attempting to lead students to problem solutions, rather than telling them outright. For each problem, students were asked to fill out a problemsolving worksheet on which they showed, in words and diagrams, the givens, the goal, and the transformation steps in their problem solutions. In addition, they were required to turn in a listing and a run of their programs. Instructional treatment lasted approximately three months. Subjects were tested both immediately before and after the entire sixunit intervention for their ability to correctly solve problems necessitating the use of each of the six problemsolving strategies. Five of the six instruments were devised by us. We attempted to make these specialized tests as independent of verbal aptitude as possible. Thus, for example, the test for forwardchaining ability was a pencilandpaper derivative of the computer game “Rocky’s Boots”;25 the analogies test contained visual as well as verbal analogies. For the sixth measure, that of students’ ability to generate alternative problem representations, we used the figures subtests of the Torrance Test of Creative Thinking.26 Different but analogous problems were given on the pre and posttests for each problemsolving technique, and differences between the two were examined using analysis of variance. The results surprised us. On the one hand, we anticipated significant differences between pre and posttest scores among contextual groupings. None materialized. On the other hand, previous failures to discover transfer effects gave us little reason to believe we would achieve significant overall differences, but, in fact, highly significant differences were found for all strategy groupings except backwardchaining (see Table 2). In particular, improvements in performance were found for subgoals, forwardchaining, systematic trial and error, alternative representations, and analogies. Such findings seem to demonstrate the transfer of these strategy skills from Logo to noncomputer domains. It is noteworthy that our finding of significant increases on the Torrance tests replicates, with an older student population, Clements and Gullo’s earlier promising results.27 Taken together with the lack of results concerning contextual groupings, however, they are not as discriminating as we would like, hence, not transparently explicable. We had anticipated significant differences among varying contextual groupings because we believed that students solving problems involving list manipulation would gain a clearer understanding of the deep structure of the Logo language and so would show greater improvement in test scores than students working solely on graphics problems. Moreover, we thought it likely that experience with both graphics and lists would be more likely to facilitate the generalization of individual strategies then either experience alone, and so would produce the greatest increases in test scores. Neither hypothesis is supported by the findings. It may be that all students’ previous experience with list processing was enough to develop a deep structural understanding of the language, or that two problems were not enough to make a discernible difference. Or it could be that the arithmetic problems, intended as a check on equivalent learning, effectively served instead as another problemsolving context, thus providing all groupings with multipledomain experience. Future research will concentrate on better delimiting each of these variables in the hope of discovering the specific cognitive processes involved in transfer. For the present, therefore, we are left with pedagogical explanations for the transfer of the particular problemsolving strategies we observed. We believe these would include the deliberate, forced attention to welldefined problemsolving ideas, the explicit modeling of the metacognitive behaviors involved in problem solution, the required working through and corresponding proceduralization of problem solutions, and the attempt to acquaint students with the deep structure of the problem domain and of specific problemsolving techniques. In a recent article, Salomon and Perkins write: “Transfer . . . benefits from a high teacherstudent ratio, Socratic interaction with the learners, great sensitivity on the part of the teacher for the ebb and flow of enthusiasm and understanding in the individual student, calculated provocation of abstraction and connectionmaking, and so on.“28 It could well be that the transfer we found results from similar features in our intervention. Most salient among these, and what may distinguish the instruction in our study from that of other such investigations, is the forced focus on problemsolving strategies and their procedural application in solving Logo programming problems. On the other hand, the feature that categorically distinguishes our intervention from those reported in other studies is that our students were as familiar with list manipulation as they were with turtle manipulation. It is our contention that experience with lists yields a far clearer understanding of the deep structure of the Logo language and that such understanding facilitates problem solution within it. We would further argue that unless problems are solved with some nontrivial degree of understanding, there can be no transfer of problem solutions to other domains. Thus, even though we found no distinctions among contextual groupings supporting our contention, we believe it possible that our students’ familiarity with list manipulation could have provided them with the critical domain knowledge necessary for understanding the particular problemsolving strategies being explored. Overall nondiscriminatory results for the test of backwardchaining ability may support such claims, in that backwardchaining is typically a novice strategy. Forward chaining is more an expert technique, based on a greater degree of domain knowledge.29 That all ages of students exhibited similar increases in this particular strategy (and no other) further supports such argument. Significant differences between pre and posttest scores among grade levels were anticipated and were found for the subgoalsformation, systematictrial anderror, alternativerepresentations, and analogies strategies. In addition, the figures reveal a correlation between test scores and grade levels for all tests except backwardchaining, indicating that our tests were in some sense discriminating, and that they were discriminating in the direction that would be expected. Moreover, differences between scores among grade levels are, in general, less than pre/posttest differences, indicating that real changes in student abilities took place as a result of the instructional intervention. The findings of differential pre/posttest differences among grade levels indicates developmental differences in the usefulness of particular problemsolving strategies. Specifically, we found greater increases on tests of subgoalsformation and systematictrialanderror strategies among younger students. These results suggest that students in the middle school grades are optimally ready to acquire these strategies. This finding is particularly interesting in that Piaget argues that it is facility with precisely these skills that indicates formaloperational skills.30 He places the onset of the formaloperational stage at twelve years of age, which falls right at the end of middle school. Correspondingly, we found greater increases among older students on tests of their abilities to generate alternative representations and appropriate analogies, which suggests that readiness to acquire these skills occurs later in a person’s development. The implications of such results for the teaching and learning of problem solving are wideranging. In our opinion, further investigations focused on these particular variables could prove most fruitful. USING PROLOG TO TEACH REASONING Thus far we have touched on the position of reasoning in determining possibilities within a problem space. This has been useful for distinguishing and explaining problem solving. At this point it seems worthwhile to look more closely at the elements of analytic reasoning in developmental terms. Perhaps the most prominent feature of analytic reasoning is its generality. The same set of reasoning tools can be found in a variety of areas ranging from science to syntax. This generality is gained through the high level of abstraction and symbolism in reasoning activity. In fact, its formal representation, predicate logic, allows one to reason without any reference to the real world. According to Piaget, abstract reasoning abilities develop in the formaloperational stage, around middle school age.31 Although there is substantial debate about the validity of positing a formaloperational stage, some of the hallmark abilities of this alleged stage of development do show up consistently in mature thinking.32 Using some of these abilities as starting points in discussion, we can at least suggest the broad targets of our research. Furthermore, attention to developmental issues might uncover optimal ages for teaching different aspects of reasoning, even if they do not fall along the lines of Piagetian developmental stages. A few salient reasoning abilities that emerge with mature reasoning are the tendency and ability to determine all the possible states of affairs and then systematically discover which is the real solution (i.e., creating a problem space and pruning it with systematic trial and error); utilizing the hypotheticodeductive method of variable isolation; using reversibility to justify a solution; and, evaluating interpropositional expressions. The hypotheticodeductive method can be understood within the context of problem spaces. Scientists hypothesize that some variable may be causing a particular phenomenon. Then they deduce what the consequences must be if the hypothesized variable is the agent. Creating a problem space from the logically predictable effects of the variable, they go to nature to confirm or deny their hypothesis. They match the logically necessary results of the hypothesis with the empirical results. The hypothesis is emphasized prior to the facts. Reversibility can also be elucidated in the context of the problem space. Reversibility is often found in mature thinking when justifying the famous Piagetian conservation tasks.33 For example, a child might justify why the short, fat glass has as much water as the tall, narrow glass: “The fat glass must have the same amount of water as the tall glass because if I poured the water from the fat glass into a tall glass it would be the same height as the other tall glass.” Reversibility is what allows one to use backwardchaining, to move from goal to initial state and inversely from initial state to goal. Interpropositional evaluations focus on judgments about the truth value of the rules or operations of a problem space. A concrete operational child can evaluate an expression like “Gertrude is in the blue house; Gertrude is not outside.” However, only an abstract reasoner could see that “if Gertrude is in the blue house, she is not outside” is true regardless of whether Gertrude and the blue house actually exist. An abstract reasoner is able to judge the validity of a statement without reference to some empirical fact. Although most people show formal operations in some areas of their life, many do not apply the rules of reasoning well in other areas. The less than peak performance of humans while reasoning is well documented. Miller and Cantor, in their review of Human Inference by Nisbett and Ross, succinctly capture the problems: If the authors’ purpose had been to belittle human reasoning, they would have had much ammunition available they did not use. Years of research on reasoning and problem solving have uncovered many glaring weaknesses . . . preference for positive instances; neglect of alternative hypotheses; overreliance on familiar content; functional fixedness; the treatment of conditionals as biconditionals and the pervasive fallacy of asserting the consequent; the tendency to delete, change or add premises; and so on.34 These failures show in typical school activities: the inability to draw conclusions and inference from reading, the difficulty in understanding the importance of a control in an experiment, and the lack of critical evaluation of political rhetoric. There is evidently room and a need to investigate whether reasoning skills can be taught using sound pedagogical principles and longterm exposure to the material. More specifically, it is worthwhile to see whether programming a computer is particularly wellsuited. Beyond the usual claims for a programming environment,35 Prolog appears to be ideal for instruction in reasoning. Teaching problem solving using Pascal or Logo involves the student in learning these languages, which may not bear directly on problem solving. Learning the correct syntax and sequence for creating a looping procedure is not intimately associated with solving classes of everyday problems. Problem solving must be specifically taught. Prolog, in contrast, is a language in which the coding of the program takes the form of logical reasoning. Learning the features and techniques of Prolog is learning the rules of reasoning. With a strong claim like this, it is worthwhile to introduce Prolog and see if there might be any truth to the assertion. Prolog represents an important alternative to more traditional programming languages like Fortran and Pascal. One might term these latter languages “procedural” languages. They act as linguistic interfaces between one’s thinking and the instruction set and architecture of the machine. One thinks of how to solve a problem and a coder (perhaps oneself) decides how to program the most efficient solution, providing a set and sequence of procedures for the computer to use in manipulating the data. The translation from thought into something digestible for the computer can be a tedious and languagespecific chore. Generally, instruction in programming is designed to help the student learn to think within the computer’s world, lessening the gap between solution and execution.36 Prolog, however, provides an interface between conceived solution and computer implementation that favors our natural reasoning and knowledge representations over the computer’s instruction set. In the following paragraphs, we will offer a brief introduction to Prolog as a “thinking” or “relational” language as opposed to the aforementioned procedural languages. Prolog is one implementation of the abstract, machineindependent formulation of computational logic called “logic programming.” Logic programming was developed by Robert Kolwalski in the early 1970s, building on computational mathematical logic. Unlike procedural programming, logic programming requires only the declaration of facts and rules in a suitable logical formalism. The “programmers” of this abstract machine need not concern themselves with the operations of the computer but rather with the interaction of the knowledge embodied in rules and facts to derive new rules and facts. An example borrowed from Walker et al.37 might prove illustrative. Let us assume that we have four cities connected by three roads, the initial state of the problem space. This could be stated in a predicate formalism as: road(city1, city2) road(city 2, city3) road(city3, city4) meaning that there is a road connecting each of the city pairs. Our concern is whether there is a route between two cities. For example, is there a route from city1 to city3? We need to come up with a relationship between roads and routes that will capture our knowledge of them. A first step toward representing this knowledge might be done with the logical relation of implication (modus ponens): route(X, Z) < road(X, Z). This states that there is a route between two locations (represented by the variables X and Z) if there is a road between these two locations. This first rule is inadequate for showing that there is a route between city1 and city3 as there is no single road connecting them. What we need is a second rule, which explains that there is a route between two cities if there are roads connecting the intervening cities: route(X, Z) < road(X, Y) & route(Y, Z). This states that there is a route between two cities if there is a road between the first city and an intervening city and there is a route between the intervening city and the second city. Given this purely declarative description of the initial state and the rules or operators that capture our knowledge of the relation between routes and roads, logic programming will yield all of the following deductions, the full problem space: road(city1, city2) road(city2, city3) road(city3, city4) route(city1, city2) route(city2, city3) route(city3, city4) route(city1, city3) route(city2, city4) route(city1, city4) Logic programming describes a hypothetical language in which all the possible deductions from a given set of assertions can be found with the programmer providing only the given facts and available operators. Programmers need only be worried about the creation of the knowledge and interactions. They do not need to worry about the techniques for implementation. In contrast, procedural languages require one to specify a procedure for making these deductions. This requires an explicit creation of data storage locations, loops for iterating the possibilities, and conditional choices for exiting loops. There are inherent difficulties in capturing the theoretical simplicity and elegance of logic programming in a computing machine. In particular, the ability to create the full problem space means that a computer implementation would be terribly slow if it made all the possible deductions and then searched for the goal state within this space. A tradeoff between the efficient specificity of procedural languages and the elegant generality of a logic programming is a knotty problem. In 1973 Alain Colmerauer at Marseilles tried to capture with Prolog the desired generality of Kolwalski’s logic programming while maintaining some degree of efficiency. Prolog has a variety of heuristics for optimizing solutions that move it away from the proposed generality of logic programming. There are constraints on the combinations of assertions one may use in Prolog and there are distinct programming techniques for ensuring a speedy solution to a problem. Short for “Programming in Logic,” Prolog leans toward the programming aspect of solving problems. Fortunately, for the class of miniproblems in which most students will be engaged, there is no practical difference between logic programming and programming in logic. Students will not need to worry about Prolog programming constraints and the uses of programming constructs like the cut and fail statements. In Prolog the steps for finding possible deductions are partially implemented through an “invisible” unification algorithm that matches assertions filling in or binding variables in one assertion to the facts of another. To demonstrate this we will introduce the two “goal” primitives of Prolog: IS and WHICH. IS determines if an assertion is true and returns the fact that made it true. WHICH tries to find all the possible situations in which an assertion is true. For example, a query like IS{X: road(city1, X)} will return X = city2. The unification algorithm will try to match the query road(city1, X) with some assertion in the program. It will find that road(city1, city2) matches and the variable X will be bound to the value city2. Here is a general delineation of the unification in a more complicated query: IS{ route(city1, city3)} 1. Try to match route(city1, city3) with an assertion in the program: route(city1, city3) MATCHES route (X Z) <road(X Z) resultant bindings: X = city1, Z = city3. 2. To see if the head “route(X Z)” with which route(city1, city3) was unified is true it must see if its condition road(X Z) is true: X and Z are replaced with their bindings city1 and city 3 respectively. road(city1, city3) does not match any assertion. Thus, the assertion from step 1 is false. The bindings of X and Z are undone and the program looks for another assertion with which it can unify route(city1, city3). 3. Prolog will try to unify with the next available assertion: route(city1, city3) MATCHES route (X Z) <road (X Y) & route (Y Z) resultant bindings: X = city1, Z = city3. 4. Prolog must now satisfy the conditions road(X Y) & route (Y Z) if the bindings from step 3 are to be considered valid. a. substituting X with city1 road(city1, Y) MATCHES road (city1, city2) resultant bindings: Y = city2. b. substituting Y = city2 [Z is previously bound to city3] route(city2, city3) MATCHES route (X Z) <road (X Z)} (1) As the assertion found in b has a condition that there must be a road between city2 and city3, this must be found true for route(city2 city3) to be true. Prolog will find this assertion in the data base. It will conclude that the condition for b is true. The condition for 4 must be true as both a and b are true. Finally, it will find the original query true as 3 must be true since 4 is true. If one made a WHICH{X: route(city1, X)} query, Prolog would find all the instances of X that would satisfy the conditions for being considered a route. Essentially, it would do the same process as above, remembering each binding that worked and returning the results: X = city2 X = city3 X = city4. The unification of variables with facts, the selection of rules to be tried, and the order of choosing the conditions to be checked is totally hidden from the programmer. This leaves programmers free to explore the knowledge and relationships required for finding the solution. Further, it allows thinkers to interact with the knowledge and assumptions they have used in trying to find the solutions for problems. Prolog’s ability to deduce anything that is deducible means that if a program is unable to find a hypothesized solution, the programmers qua thinkers must review the knowledge they think characterizes the requirements for the solution.38 As this knowledge is in a declarative and logical format, it is readily inspectable by natural reasoning methods. Errors found are errors in thought, not in program construction or improper syntax. Sterling and Shapiro summarize this nicely: We think that programming can be, and should be, part of the problem solving process itself; that thoughts should be organized as programs, so that the consequences of a complex set of assumptions can be investigated by “running” the assumption; that a conceptual solution to a problem should be developed handinhand with a working program that demonstrates it and exposes its different aspects. . . . In contrast, formalizing one’s problem and method of solution using the von Neumann instruction set [procedural programming languages] rarely has these beneficial effects.39 Prolog until recently received little attention in the United States. However, with its acceptance as the official language of the Japanese Fifth Generation Project in 1981, Prolog moved from an obscure language into the forefront of artificialintelligence work. With its general theoremproving ability, use of symbolic data, listprocessing abilities, and efficient search methods, it is offering a viable alternative to McCarthy’s functionoriented language LISP. More important for our concerns as educators, several appealing microcomputer versions are now available.40 It is interesting to speculate about the role of Prolog with the recent development of parallel computers. The ability of parallel computers to do several operations simultaneously will require a dramatic change in typical procedural languages, which assume that operations occur sequentially. On the other hand, logic programming makes no such assumption, as it does not bother the programmer with problems of explicitly guiding the machine. Prolog can capture the power of this new generation of computers without changing the nature of the programming activity. With the advent of parallel machines, new programming logics will be developed that do not require the constraining heuristics of Prolog to work efficiently, yet they will share the commonality of being based on logic programming.41 We can now begin to describe how Prolog can be used to teach reasoning to students. The results of our current research project to evaluate empirically the use of Prolog to teach reasoning to middleschool students are not yet available, so we will illustrate this approach by presenting two examples of the instructional activities that are feasible for immediate use given little exposure to Prolog: reversibility and AND relationships (intersections) for defining membership. Although our instruction will use more elaborate interfaces built on the Prolog environment (e.g., a prebuilt data base, an expert system shell, a natural language frontend, and a frontend capable of graphically representing the knowledge relationships), the following exercises are easily implemented in any Prolog environment. Reversibility is the ability to recognize that operations undo one another. The operations of subtraction and addition are an excellent example. As children develop a more sophisticated understanding of arithmetic they should come to learn the reversibility of these operations.42 A reasonable objective would be that the child should be able to demonstrate several operations that undo one another. At the more specific level of mathematics, the child should be able to use subtraction to solve a problem written in the form of 3 + X = 9. Prolog, as does reasoning, uses reversibility extensively to solve problems. In fact, most Prolog environments provide only the two primitives PLUS and TIMES for integer arithmetic. Subtraction and division answers are found by asking the computer to find the inverse relationships implied by PLUS and TIMES. A teacher might show the students how to do addition problems in Prolog: PLUS(2 3 X) Prolog would find the value of the variable X to equal 5. The teacher might elicit suggestions or ask students how to do subtraction. Eventually, it should come out that subtraction can be found by moving the variable to an addend position: PLUS(2 X 5) would yield X = 3. Moving X to the first position would give X = 2. The teacher might then ask the students to try some division problems using TIMES. Once these operations are mastered they can be used to elaborate on the role of interconstraining variables in an equation (an example of interpropositional evaluation). For example, TIMES(X Y 20) gives all the factor pairs of 20: X = 1, Y = 20 X = 2, Y = 10 … X = 1, Y = 20. This can be elaborated on depending on the inclinations of the class to create a program that finds the greatest common factor of two numbers. For some Prolog versions, this requires a single implication: GCF(X Y) < TIMES(A B X) AND TIMES(C A Y) and PRINT(A). The PRINT(A) will force Prolog to display the answer bound to A. Once this implication has been typed into the computer (according to the syntactical requirements of the system, usually trivially different from the above version), questions about greatest common factors can be answered. To find an answer one might query: WHICH {GCF(14, 21)}. To check a proposed solution one might enter: IS{7 <GCF(l4, 21)). Students can explore the role of variable positions within the GCF implication as a general unguided exploratory activity. An enrichment activity might consist of writing an implication that finds the least common denominator of two numbers: LCD(X Y) < TIMES(X A Z) AND TIMES(Y B Z) AND PRINT(Z). Clearly these latter activities are of some difficulty to work through and depend tremendously on teacher and student competence for success. However, the initial lesson on reversibility should be simple and useful. Another simple activity, introducing the notion of necessary attributes and intersections, would involve creating a data base and using the conjunction AND in queries. The first step is to settle on a formalism for entering facts into the data base. A simple one might use the two predicates HAS and ISA, which will each accept two arguments: HAS(RedHair Mary), ISA(Female Mary). Once this is decided on, teachers might have students enter facts about themselves into the computer. They might require that at least the students include statements about hair color, height, age, and so forth. One’s imagination is the only limitation here. Once the computer users have entered their facts, the class’s facts should be transferred via disk to one computer. Teachers will then ask if anybody would like to find out about something in the data base. Questions will probably take the form of IS{ ISA(Female Mary)}. These are factual questions. More abstract questions can take the form of WHICH{X : ISA(X Mary)}, which will give all the ISA information about Mary. Students might be engaged in a conversation that discusses the different results if one asks WHICH{X : ISA(Female X)}. This latter question will give all the females in the data base. Once this initial grasp of the data base query and the use of variables is developed, students are ready to move on to the concept of conjunctive constraints (or necessary but singularly sufficient conditions) for class membership. As an example the teachers might say that they would like to make a club of all the children who have blonde hair and are lefthanded. How might they query the data base to find out who could belong? One likely answer is to make a query that asks for all the lefthanded people and then write these names on the board. Next make a query for all the blonde people and write these on the board. Then one could see who is in both groups. A discussion revealing the terms necessary and sufficient could ensue. That is, lefthandedness and blondeness are necessary attributes but by themselves are not sufficient for belonging to the club. Using Venn Diagrams to help illustrate set membership, teachers could then introduce the use of AND in simplifying the query: WHICH{X : HAS(Blondehair X) AND ISA(LeftHander X)} Once the notion of an intersection or conjunctive relationship is firmly in hand, a class might try to create some predicates that define the members of a set: BELONGTOTEACHERSCLUB(X) <  HAS(Blondehair X) AND ISA(LeftHander X) Students can then use the new predicate to simplify their queries. This begins to introduce the notion of a conditional; X is true if Y is true. Although the students are probably not ready to evaluate the implications of conditionals, this would serve as a good introduction to the utility and form of conditional expressions. A venturesome class might begin to build complicated definitions that build off of other implications: BELONGTOMYCLUB(X) < BELONGTOTEACHERSCLUB(X) AND HAS(Money X). These lessons attempt to give a flavor of the flexibility and relative ease of using Prolog for a variety of reasoning problems. With a thoughtful development of instruction, students could develop quite an impressive structure of reasoning and programming skills. Using basic reasoning constructs, children could eventually create interactive computer games by specifying the rules of play and the facts that represent the “game board.” They might even be able to make the computer a good opponent in such a game. During all the students’ projects they will be learning and operating with highly abstract reasoning. OTHER THINKING SKILLS We have chosen to discuss a few thinking skills in some detail here in order to illustrate how computers can be used effectively to convey them to students. However, we do not mean to imply that only these kinds of thinking skills can be conveyed by computer. Critics of computer uses in education have argued that computers can be used only to teach the sorts of rule oriented thinking skills we have emphasized here.43 Few would argue about the value of these ruleoriented skills, but clearly they do not encompass all human thinking skills; to limit the curriculum to these alone would be a disservice to students. The capabilities of computers are not, however, limited to conveying general rulebased thinking, as a brief discussion of reasoning from images and from specific experiences—skills frequently cited as slighted in computer use in education—will show. Suppose we want to teach students about how a steam engine works or how radio and television waves work. Understanding how such devices work involves heavy use of mental simulation utilizing the human imagery system.44 For example, in order to understand what happens to radio and television waves in a big city with tall buildings, students have to use dynamic mental images to visualize waves spreading out in spherical wave fronts from an antenna, then parts of the waves reflecting off the tall buildings to set up an interference pattern. Similarly, with the steam engine, students need to be able to visualize what happens as various valves are opened to certain levels and water or steam flows through various pipes and chambers. Students can gain some insight into steam engines by manipulating toy steam engines, but that alone cannot teach them how to visualize and simulate the internal workings of the engine. This mental simulation ability can be conveyed effectively using a computerized graphic simulation of how the steam engine works; in fact, the Navy uses such a computerized simulation to train boiler room personnel for Navy ships.45 The radio and television wave example is even more compelling: Because radio and television waves are invisible, there is no way students can physically manipulate them to see what happens in the real world. A graphic computer simulation serves as a powerful way to convey the dynamicimagery thinking abilities students need to reason about such wave behavior. The research of Taylor and Cunniff provides another example of the use of graphic computer displays to convey imagistic thinking skills to students.46 In particular, Taylor and Cunniff have shown that teaching students programming using a graphic programming language eliminates many misconceptions and allows the students to comprehend programs faster. Thus, far from undermining human imagery skills as some critics have suggested,47 the use of computers in education provides a more effective way of conveying how to think in images. Another criticism of the use of computers in education is that it encourages students to believe that learning general rules is all that is involved in learning to think.48 No one would want to be treated by medical school graduates who know all the general rules of medicine but have had no chance to supplement this general knowledge with the experience provided by a residency. In fact, this notion that a true expert reasons not just from general rules but also from specific experience is a powerful idea that should be taught to students. As the critics have charged, teaching students simple turtle graphics in Logo does not provide an environment in which to teach the value of reasoning from experience and may even discourage students from thinking that way. This point is a specific instance of a more general point made by McClintock—that educational computer systems to date are informationally impoverished, that is, they do not contain anywhere near the amount of information that is contained in books.49 However, as McClintock goes on to point out, this is changing as more powerful computers with immense storage capacities become available. In fact, storage media like CDROM can store much more information than books (a single CDROM resembles a small library more than a book). However, just providing large amounts of information is not enough; students have to be taught to reason with it effectively. We argue that the kinds of strategies for using computers in education described earlier can be used to teach students to utilize both rulebased and experiencebased reasoning. Although Logo can be used for this purpose if the usual turtle graphics programming is supplemented with list processing, Prolog is particularly convenient for conveying this idea because of its clear delineation of general rules, specific rules, and specific facts. In particular, students focusing on creating general rules when programming in Prolog will quickly run into trouble (i.e., have awkward programs that do not function effectively) and realize that they need to add specific, contextsensitive rules and structured descriptions (using list structures) to the general rules they began with. While we have no illusions that these representations completely capture knowledge acquired with human experience, they do capture some of it and illustrate to students in a compelling and concrete fashion the need to coordinate rulebased and experiencebased reasoning.


