A Little Experiment!

K-12 programming experiences seem to be on the decline. However, there are still enthusiastic supporters. Convention presentations we attend still promote programming experiences or report research findings evaluating the potential benefits. It is not that programming has negative consequences. Perhaps those operating most schools have reached the same conclusion about programming that we have reached about our book -- there is simply not room or time for everything.

The Internet offers us an option. We can ignore the market studies on "most valued topics" and offer content that is of interest to some instructors in some situations. I read a Science article once authored by a physics professor who lamented the homogenization of Physics texts because everyone was worried about covering the "main topics". His concern was that the result would be a generation of physicists all with the same perspective. What in the collective knowledge base would serve as a source for creativity if everyone had been prepared to view the discipline in the same way? If anything, we feel education is a field in even greater need of creative perspectives.

So -- here is part of our effort to encourage a broader perspective. Think different!

Developing Higher-Order Thinking Skills Through Programming

WHAT IS PROGRAMMING?

Programming is the process of instructing the computer to perform some desired action. The learner manipulates the computer. Think of it as teaching a student with perfect memory but very limited capacity to interpret what you say. Unless your instructions are explicit, accurate, and detailed, the computer will be unable to understand what you would like it to do. If you are familiar with the classes that computer science majors take, you might equate programming with some image you have of a programmer sitting at a computer terminal typing in code in BASIC, FORTRAN, Pascal, C+, or some other recognizable high-level programming language. It is useful to take a somewhat broader perspective.

Programming has not always involved the specialized languages we recognize today. Early programmers did not type in programming instructions using keyboards, but used a series of toggle switches to enter commands in binary (1’s and 0’s); that is, each unique combination of 1’s and 0’s told the computer to take a very specific action. The world of technology has changed a great deal since then. Higher-level languages now allow programmers to work with commands and ways of combining commands that are easier to learn and easier to enter into the computer than the binary coding. Still, learning these commands and what they do and learning the rules that define how the commands can be combined according to the grammatical rules of the language take a considerable amount of time. The programming techniques of the future may also be very different from today’s techniques. Already, some  programming environments take a visual approach and allow the "programmer" to arrange icons (miniature pictures) representing different computer actions. Later, we show you a type of programming in which the computer can be "taught" through a form of demonstration. The programmer "shows" instead of "tells" the computer how to act in a specific situation.

So it is useful to take the perspective that programming can take many forms and different types of programming are evolving to meet different purposes. Once programmers get past the challenge of providing instructions to the computer, either because they have mastered a programming language or because the technology has been adapted to allow some other form of input, manipulating the computer or a device controlled by the computer is a matter of explaining exactly what it is the computer is to do. The challenge at this point is easily underestimated and is much more a matter of higher-order thinking than memorizing the factual information of programming commands and rules.

Why Learn to Program?

Programming experiences in schools serve three functions. First, programming is a skill that some believe is important to learn; it provides an understanding of the functioning of the computer and computer software and thus is one way to develop certain aspects of general computer literacy. And for a few students, it may eventually become a profession. Second, programming has been advocated as a powerful environment within which problem solving or some other general cognitive skills can be developed. A great deal of work is in progress to test this claim and to create classroom environments in which the overall benefits of learning general problem-solving skills through programming might best be realized. Finally, programming may allow students to learn the content of some other discipline, such as geometry. It appears possible that programming can provide an active way to explore and construct a personal understanding of content within certain disciplines.

Here, we explore these final two claims. We emphasize these issues because we see them as important to decisions that educators must make about how students will spend school time. Will students have programming experiences or not? Before this discussion will make much sense, you will need to gain some insight into the programming experiences that students might encounter.

Why Emphasize LOGO?

Programming in LOGO

The customary method for introducing students or teachers to the LOGO language is through experiences with turtlegraphics. The most common version of turtlegraphics relies on a small-screen turtle that moves and draws on the computer screen. The screen turtle’s actions are controlled directly by commands issued from the keyboard or indirectly by programs constructed by a programmer. Examples of drawings created with turtlegraphics are scattered throughout the material that follows

The individual commands in LOGO are called primitives. As is true with commands in all other programming languages, LOGO commands must follow an established syntax. The syntax for individual commands consists of rules for combining keywords, punctuation, and arguments. In LOGO, commands follow the format keyword [space] argument (Fay & Mayer, 1988). For example, if you wanted the turtle to move ahead thirty turtle steps, you would issue the command forward 30 (abbreviated as FD 30). In this example, the keyword is forward (or FD), the punctuation is a space, and the argument is the number 30. Expressions such as 30FD, 30 FD, or FD30 are incorrect and will not work. If all of this seems unnecessarily complex for young children, just stop to think about the rules they follow in writing English. Whereas young students would probably be unable to apply appropriate terms to the components of a LOGO command, they are quite capable of learning and following the rules necessary for constructing commands the computer can interpret.

We strongly encourage you to take the time to experience programming. The best way to appreciate LOGO is to spend some time at a computer exploring the features of the language. As you begin, contemplate your own thinking. Insights you have about your own thinking might be helpful when you work later with other beginners. You might want to consider the following questions. What about your experiences do you find frustrating or exciting? What approach do you take when something does not work as expected? How do you feel when you finally solve a problem that has stumped you for some time? (One of us has been known to cheer and punch his fist in the air!)

Programming in Direct Mode

Now, instead of individual commands, try entering the following sequence of commands before pressing the return key: FD 30 RT 90 FD 30 RT 90 FD 30 RT 90 FD 30 RT 90 .

Programming in Indirect Mode: Writing Procedures

In LOGO, a set of stored instructions is called a procedure. The general format for a procedure is:

TO procedurename

commands

END

To generate a square as a procedure, you might enter the following list of commands:

TO SQUARE

FD 30

RT 90

FD 30

RT 90

FD 30

RT 90

FD 30

RT 90

END

In direct mode, the entire sequence of commands can now be executed by simply entering SQUARE (then press Return). The procedure SQUARE has been added to the LOGO vocabulary. In a way, the programmer increases the power of LOGO by contributing to what LOGO knows how to do. This is what we mean by describing programming as "instructing the computer."

What if you made a mistake–say, you incorrectly entered 3 instead of 30 for one of the sides? The figure drawn by the procedure would not be what you anticipated.

However, the process of correcting the error is relatively easy. You simply return to indirect mode, examine the procedure to find the error, and make the necessary correction. You can now execute the procedure again. If your modification fixes the actual bug, your program should execute as intended.

Additional Features of LOGO

TO SQUARE

REPEAT 4 [FD 30 RT 90]

END

Powerful programming languages also make use of variables. The value of a procedure such as SQUARE would be limited if you had to rewrite the procedure every time you wanted the turtle to draw a square of a different size. In a way, variables allow you to establish the sequence of actions to be taken when the program is written and to defer assigning specific arguments to these actions. To write a more flexible version of the square procedure, you could establish the length of a side when the procedure is actually executed. You could write this more flexible version of the square procedure this way:

TO SQUARE :SIDE

REPEAT 4 [FD :SIDE RT 90]

END

Once you have created the square procedure, you execute the procedure by entering SQUARE followed by the length of the side you want (for example, SQUARE 40). If you forget and enter only the procedure name, LOGO will ask you for the missing value. ?The way LOGO designates and uses variables might be a bit confusing at first. SIDE is a variable name. When a variable name is preceded by a colon (as in :SIDE), this means the value of a variable. When the REPEAT command encounters FD :SIDE, it substitutes the value of SIDE. To establish the value of a variable, you can also use the primitive MAKE "variablename value (as in MAKE "SIDE 40). Instead of entering SQUARE 40 to draw a square 40 turtlesteps on a side, you could also enter the command MAKE "SIDE 40 and then the command SQUARE :SIDE to accomplish the same thing. To keep these different ideas straight, you might think of a variable name as a storage place, like a box somewhere in the computer’s memory. The MAKE command attaches the variable name to a storage location and allows you to put information in this storage place. When the value of a variable is requested (as in :SIDE), LOGO will check the designated storage location to obtain the needed information. If LOGO finds an empty storage location, LOGO will generate an error message and ask for the needed information (in LogoWriter, SQUARE NEEDS MORE INPUTS).

Building a Program with Procedures

TO WISH

MAKE WISH1

WISH

END

Recursion can also be demonstrated as a way to extend and produce some interesting effects with procedures that have already been written. The procedure that follows uses SQUARE. There are no repeats in this procedure, but many squares of decreasing size have been drawn. In fact, an IF statement was included to stop the program from going on and on. The results are shown below.

TO BLACKHOLE :SIDE

SQUARE :SIDE

RT 12

Make "SIDE :SIDE*.985

IF :SIDE.5 [STOP]

BLACKHOLE :SIDE

END

Now that you have had a brief exposure to the kinds of programming that younger students might do, the question becomes what these experiences accomplish. The remainder of this chapter addresses this question.

An extended example

Programming and the Development of Problem-Solving Skills

On the surface, the argument that students can learn general problem-solving skills from programming experiences seems logical. Programming is nearly a classic problem-solving activity. Descriptions of what experienced programmers do (Pea & Kurland, 1987) are almost identical to more general descriptions of the problem-solving process (Bransford & Stein, 1984; Hayes & Simon, 1974). As the programmer attempts to accomplish a programming task, he or she must:

• Understand the task.
• Develop a plan for completing the task on the computer.
• Convert the plan into programming code.
• Evaluate the extent to which the program functions as desired and modify the program when necessary.

Do students learn to become better problem solvers because they have spent time learning to program? Providing a direct answer to this question is difficult. Various reviews of the research attempting to summarize this issue have not reached a unanimous conclusion (Keller, 1990; Pea & Kurland, 1987b; Salomon & Perkins, 1987).

Reasons for Conducting an Overview of the Research

• Becoming familiar with the research will help you when you are trying to make decisions about how to integrate technology effectively into your classroom. If you decide to provide your students with programming experiences, for example, you should attempt to determine whether programming benefits them and which approaches to teaching programming seem most productive.
• The research literature provides an example of the evolution of theory and related ideas about classroom applications. Consideration of this body of work demonstrates that the results of research studies can cause recommendations for practice to change.
• Because nearly all of the research on programming and problem solving was conducted in classroom settings, it provides insights into how teachers use LOGO. The impact of LOGO on student behavior is directly determined by the actual experiences of students, not by the potential experiences that are never realized.
• The studies seem to lead to recommendations for practice that mesh with many of the ideas developed in Chapter 2: cognitive apprenticeship, authentic tasks, and learning for transfer or application.

Early expectations of LOGO may have been overly optimistic. When new and promising educational ideas do not deliver as advertised, the educational community often drops the ideas and looks for the next innovation. We agree with those who caution against this reaction and suggest that educators treat the educational application of LOGO itself as a LOGO program that does not work as anticipated. Even an inexperienced programmer realizes that a complex program often does not run on the first attempt, and the appropriate response should be to evaluate the program and its assumptions carefully rather than abandon the work that has been completed.

Conditions for Low- and High-Road Transfer

The process by which specific skills and knowledge learned in one situation prove generally useful in a variety of new situations is referred to as transfer. When you think about it, transfer is what formal education is all about. Unless what we teach and learn in our classrooms has some general value in other classrooms and outside the school setting, why bother acquiring the knowledge in the first place?

Transfer can occur in two ways, sometimes referred to as low- and high-road transfer (Salomon & Perkins, 1987). In low-road transfer, behavior is practiced extensively and in a variety of situations and learned to the point of automatization. Automatized behavior is behavior that a person has learned to the point at which he or she can complete a task without thinking about it. For example, if you drive or are a competent typist, you have practiced skills extensively and in a variety of situations and have likely automatized behaviors related to typing and driving. When you type the letter q, the fact that the little finger on your left hand moves straight up one row is probably not something you are aware of.

In high-road transfer, skills must be deliberately transferred from one context to another. Two requirements must be met. First, the individual must be capable of re-representing the original skill at a level that will include a greater range of cases than was covered by the context in which the original skill was first acquired. For example, if a student both observes from experiences with programming and is capable of explaining that it is often useful to take a complex problem and identify individual tasks to be accomplished, the student has re-represented programming knowledge in an abstract and verbal fashion that would apply to many tasks. Second, the student must be willing to make a conscious effort to use past experiences to attack current problems. Such an approach requires both motivation and metacognitive skill.

Identifying whether studies met the requirement for either high- or low-road transfer turned out to be an accurate way to predict whether the studies were successful in demonstrating the transfer of problem-solving skills (Salomon & Perkins, 1987). To summarize, when students did not

(1) spend enough time programming to develop a reasonable level of skill or accumulate enough diverse experiences,

(2) consider and discuss how they solve problems when they program, and

(3) consider how the problem-solving skills involved in programming might apply to other domains, the research studies were unlikely to demonstrate that students could transfer programming skills to other areas.

Issues in Implementing LOGO

The original philosophy of LOGO stressed the importance of personal discovery within a responsive exploratory environment. Many teachers appear to have interpreted the initial guidelines for working with LOGO as advocating little planning or intervention on their part (Keller, 1990). As a result, they typically introduced students only briefly to commands or techniques and then allowed them to explore on their own. Observation of students’ behaviors under these circumstances indicated that they found the LOGO environment to be motivating. However, whatever the expectations, most younger students working in LOGO do not spontaneously engage in the general problem-solving skills thought to be prompted by programming environments. Without specific guidance, many students would find some set of commands that produced an interesting pattern and fiddle with this pattern by entering slightly different values for the key variables (Littlefield et al., 1988). They might continue variations on the same theme for several class periods using a trial-and-error approach. Researchers noted that students seemed highly motivated and intrigued with the interesting results their programs would produce, but that they were frequently unable to predict what a specific version of the program would do before they ran it or explain why particular results were produced. These observations suggest that many students engage in only weak problem-solving practices when they are allowed complete freedom to explore. In terms of the principles we discussed in Chapter 2, it seems that the external activity of programming within a discovery environment often does not engage internal processes thought to be important components of problem solving.

A Matter of Style

These observations of students’ programming have implications for teachers and schools that want to use LOGO or other languages to develop problem-solving skills.

First, the analysis suggests that educators take a more realistic look at what they expect LOGO to accomplish. At best, students in elementary and junior high school settings are likely to spend thirty to fifty hours in a year programming (Pea & Kurland, 1987b). Schools have many instructional responsibilities, and it may not be practical to assume that they can increase this time commitment substantially. Perhaps it is necessary to accept the reality that students will not become very proficient as programmers in thirty to fifty hours, especially when they use much of the time in self-directed discovery. The solution may be to switch away from pure discovery experiences. This is the approach taken by educators who advocate more structured and mediated (but not lock-step) approaches to LOGO instruction.

Second, it appears that the development of problem-solving skills requires guidance. Increasing the amount of structure in the learning environment seems to improve student knowledge of LOGO, but it does not appear to be sufficient to develop general problem-solving skills (Littlefield et al., 1988). It appears that more general skills can be developed when teachers employ mediated instruction (Keller, 1990; Littlefield et al., 1988). In a mediated instruction approach, the teacher works directly to develop the thinking skills or strategies associated with the academic task the student is performing. The teacher must take care to establish that he or she is as concerned with the development of important thinking processes as with more visible products. When the content taught by mediated instruction is programming, key thinking processes might include planning, breaking complex problems into smaller problems, and using a systematic approach to identify and fix bugs. In contrast, the products are the program code and the result of the program (a graphic design when using turtlegraphics).

Students need to be told that planning and other cognitive activities are important, taught how to perform these skills, and monitored to make certain they use the skills. Because of the broad educational expectations associated with programming, it might also be useful to ascertain that students understand that the targeted cognitive behaviors may be processes involved in general problem solving.

Planning, breaking down complex problems, and debugging are useful processes in many arenas, but it appears that the transfer of these skills to general applications is not automatic. Thus, mediated instruction might also concern the conscious transfer of skills learned in one domain to other settings and other problems. Teachers might ask students to think about how planning or debugging skills emphasized in programming might apply to writing or preparing a speech. Students must understand that they are learning skills they will be expected to apply in a variety of areas.

Mediated instruction involves a number of techniques. First, the teacher makes critical strategies explicit. Then he or she can mention specific skills and demonstrate them through think-aloud techniques. The teacher can demonstrate how to debug a faulty program and discuss how to bridge thinking skills learned in programming to other areas. For example, Littlefield et al. (1988) discuss applying processes from programming to plan a class party: What are the components of the problem, and what has to be done to prepare for each component? Second, mediated instruction attempts to involve students in thinking about and analyzing their own thinking and behavior. This can be a very different process from telling students what to do or evaluating the product of what they have done. Teachers seem to communicate differently when teaching LOGO than when teaching other subject matter. They provide fewer instructions and ask more questions (Emihovich & Miller, 1988). The questions often are not requests for information but are intended to get the students to think about their own behavior.

A sequence of such questions might include: What did you tell the turtle to do? What did you want it to do? How are you going to fix it? (Au, Horton, & Ryba, 1987; Clements & Gullo, 1984). The use of questions is also opportunistic; teachers must generate the appropriate questions in the appropriate situations.

The relationship between programming and other content areas may not be intuitively obvious. The programming examples in this chapter may have involved concepts you recognize from other content areas. For example, you may relate the concept of variables to an algebra course. Papert (1980) saw the relationship as potentially much more general. To understand his view, it is useful to appreciate his vision of a computer microworld. A computer microworld provides an environment representing some discipline. The student can explore and manipulate this environment and experience systematic consequences as a result of actions taken. These consequences allow the student to construct an understanding of the environment through processes of assimilation and accommodation. Papert adopted the ideas of assimilation and accommodation from Jean Piaget. In assimilation, external experiences are interpreted as fitting with existing mental structures. In accommodation, mental structures are changed to fit experiences. These interacting processes describe the development of personal understanding by construction (see discussion of constructional theory in Chapter 2).

Turtle Geometry

The LOGO turtle provides access to the microworld of turtle geometry. Papert (1980) argued that geometry is understood through action and that turtle geometry is just another style of "doing geometry." Euclid’s style was logical, Descartes’ style was algebraic, and the turtle’s style is computational. If you find this a bit abstract, think about your own understanding of the concept "circle." You may represent a circle as a definition: a closed plane figure with all points equidistant from a common point. As an algebraic expression, a circle can be represented as x2 + y2 = r2 (assuming the Cartesian center is 0, 0), with r representing the radius of the circle. If you fix the radius as 1, the unit circle can be defined as x2 + y2 = 1. A circle can also be represented as the product of a LOGO program. Most students willing to experiment with LOGO eventually come across the simple program REPEAT 360 FD 1 RT 1. For a more sophisticated method for generating a circle, consider the following procedure (based on Yoder, 1992):

to CIRCLE :RADIUS

REPEAT 360

FD :RADIUS

WAIT 10

PD

FD 1

PU

BK 1

BK :RADIUS

WAIT 10

RT 1

END

If you have an opportunity, enter these commands and run the program. The program draws a circle with the radius you specify. The turtle moves forward the distance you have specified as the radius, puts the pen down, and moves forward one step. This creates a point. The turtle then puts the pen up and moves back to the center of the circle. Finally, the turtle turns one degree to the right. This sequence is repeated 360 times. If you watch the turtle repeatedly run out, make a mark, and then run back as it generates the circle (the WAIT commands have been inserted so that program execution slows down), you may understand what a circle is in a different way than you would if you just thought about "a closed plane figure with all points equidistant from a common point."

Certainly the computational method of defining shapes is the only method among those briefly presented here that defines geometry in terms of action (movements of the turtle). Young children intuitively understand spatial notions in terms of action and the LOGO approach (Battista & Clements, 1988). One experience cited in support of this claim is the frequently observed tendency of children (or adults) to "become the turtle" to solve LOGO problems. You can watch children moving their bodies as they think about a problem. Teachers often suggest that students become the turtle when students want help. Try it. Can you walk in a circle? Translate what you are doing into LOGO commands. Would your program read, "Move ahead a little, turn a little, ahead a little, turn a little, and so on"?

Although it is most frequently used with elementary or junior high school students, LOGO is not limited to understanding only the most basic features of geometry. Turtle geometry can be used to explore advanced topics in geometry as well (Abelson & diSessa, 1981; Yusuf, 1995).

LEGO-LOGO

An interesting extension of LOGO is LEGO-LOGO (Rosen, 1993; Shimabukuro, 1989). LEGO-LOGO allows the student to build simple machines and then uses the computer to control the machines through an interface box. The LEGO kit includes blocks, motors, gears, touch and photo sensors, and a counting mechanism. These extensions allow some new and interesting programming problems. New LOGO primitives (such as ON, OFF, REVERSE DIRECTION) are provided. In addition, the LEGO-LOGO microworld allows the exploration of certain topics in physics, engineering, and mathematics. Because the machines move and lift, physical properties such as force, work, weight, friction, speed, time, and distance come into play. The sensors can be used to gather data for analysis. For example, the photo sensor can detect when an object breaks a beam of light. The object could be the car a student has built, and detecting when the car passes a certain point can be used to determine how long it took the car to move a certain distance–from the start line to the finish line, for example. You can imagine the potential for a LEGO-LOGO drag strip and a little friendly competition! However, the LEGO-LOGO microworld should also encourage the development of both programming skill and content-area knowledge. Could you write a program to determine the speed of the cars? What is speed, anyway?

Programming Microworlds: Learning with Stagecast Creator

There are two unique problems in learning to program. First, programming requires the learner to master an entirely new language. Second, programming languages are artificial rather than natural languages. Core concepts in the language–things like data structures and iterative algorithms–are based on the way computers and not people think. In a way, programming requires that you learn how a computer works. If this knowledge takes a considerable time to acquire and yet has little value for the learner, other potential benefits of the process of programming or the tasks that can be accomplished with programming skills may be ignored (Smith & Cypher, 1999).

Various efforts are under way to develop programming methods that "move the computer closer to the learner" rather than to expect the learner to "move closer to the computer." One approach that seems particularly suited to the learning experiences we have decided to emphasize has been described as analogical programming (Smith & Cypher, 1999). In analogical programming, the programmer performs actions that are analogous to the effects to be produced by the program. Think of this as "programming by demonstration." To make this possible, developers must first create customized programming environments for a category of programming tasks. For a carefully defined set of tasks, programmers can then (1) identify a situation and (2) demonstrate what the programmer wants the computer to do when it encounters the designated situation.

Stagecast Creator, a customized programming environment developed for younger learners, allows analogical programming to be applied to the development of simulations, animated stories, or instructional tutorials and games. Activities using this programming environment could be integrated into many content areas and thus encourage the dual-agenda approach of developing content-area knowledge and higher-order thinking.

Stagecast Creator allows programming within an environment defined by these elements:

• A stage (background) divided into equal-size areas
• Characters (objects)
• Rules that define the actions of characters

These features all allow customization by the programmer. All of the features can be seen in the following figure.

The stage in this case is a solid color, although it could contain a scene suited to the application being developed. The grid structure that defines the discrete areas of the stage is visible only when a program is being developed. You see three characters on the stage. Again, the appearance of any object is limited only by the artistic skill of the programmer. The "Rule Maker" appears on the screen because the programmer is in the process of demonstrating what the program should do when a dark-colored object is located to the left of a light-colored object. What you see being developed is a simulation that attempts to demonstrate Mendelian genetics involving a hypothetical organism (the character) with a single gene. The gene has a recessive and a dominant trait. The homozygous organisms are dark (both dominant versions of the gene) or light (both recessive versions of the gene). The heterozygous organism (one dominant and one recessive gene) has a mixed appearance (actually the heterozygous organism would probably be dark, but this simulation shows two colors so heterozygous organisms are visible). The rule you see being established ("mate") tells the computer what to do when a dark character is positioned to the left of a light-colored character. The pair "gives birth" to a heterozygous character. The rule is created by demonstrating the "before" and "after" conditions and is attached to the dark colored character. Examine the figure carefully to see how this is accomplished. Note that before the rule is implemented, the space below the character on the right is vacant. After the rule has been implemented, the same space contains a heterozygous organism. Computer scientists refer to the programming technique of attaching programming code to a defined object as object-oriented programming and this technique is a fundamental feature of many advanced programming languages.

If you remember a little about genetics and have begun to think about this simulation, you can probably anticipate some of the many tasks the programmer would have to accomplish. One of the most basic tasks is to program characters to move about in such a way that from time to time they bump into each other. The programmer can demonstrate how a character is to move. For example, the character can be shown that if the space to the right is vacant, move into that space. The same character can be shown that if the space down and to the right is vacant, move into that space. Creator offers the programmer the opportunity to develop what programmers would call subroutines. A subroutine is a combination of programming statements designed to accomplish a specific task. In Creator, a subroutine is established by putting multiple rules in a folder and then defining the relationship among the rules. For example, if we wanted to create a subroutine that would cause one of the characters to move about in an erratic fashion, we might put the two movement rules just described in a folder and specify the relationship among the rules as random. This movement folder would cause our object to move to the right–sometimes directly right and sometimes in a downward direction. Other subroutines allow multiple actions to be taken in response to a specific condition or allow a sequence of actions to be taken as long as the necessary conditions are met.

AgentSheets - another programming environment

LEGO-LOGO and Creator provide examples that involve a form of programming and content-area learning. Both examples are still dual-agenda approaches.

SUMMARY

Programming is the process of instructing the computer to perform a desired action. Programmers communicate with the computer through specialized languages, each of which has a unique vocabulary and requires the use of a formalized syntax.

LOGO was developed as a programming language for the educational environment. An important characteristic of the LOGO language is the use of procedures–stored sets of instructions. Ideally, procedures are developed to perform one clearly defined task. Procedures can also be combined to perform more complex tasks.

Programming has been proposed as a way to develop student higher-order thinking skills. Educators can emphasize higher-order thinking in several ways: a stand-alone course, a dual-agenda approach combining instruction in higher-order thinking and content-area knowledge, and authentic tasks that require the use of higher-order thinking and the learning of content knowledge. LOGO programming is an example of a dual-agenda approach.

Although programming is a good example of problem solving, evaluations of the use of programming experiences as a way to teach problem solving are inconclusive. Careful examination of programming experiences provided for this purpose reveals some potential problems. Proposed solutions to these limitations include the development of more structured learning experiences and the use of mediational teaching methods, which focus on the cognitive processes used in performing particular skills. In general, the teacher attempts to make these internal processes more understandable to the student and influence the development of these skills.

Programming can also provide an active way to learn a content area. The LOGO turtlegraphics environment was developed as a geometry microworld. When operating in this setting, the student can engage in a computational style of representing geometric principles and concepts. LEGO-LOGO may provide a similar type of environment for learning principles of physics. Other ways to apply programming in content-area instruction are being developed.

Programming courses may not be educationally efficient. Projects provide an authentic way to investigate topics in content areas and also to develop higher-order thinking skills. Such projects would be included in existing content-area courses. Technology can be used as a tool enabling students to measure various characteristics of their physical world. The design, implementation, analysis, and presentation of research based on these data provide the basis for authentic projects.

Abelson, H., & diSessa, A. (1981). Turtle geometry: The computer as a medium for exploring mathematics. Cambridge, MA: MIT Press.

Au, W., Horton, J., & Ryba, K. (1987). Logo, teacher intervention, and the development of thinking skills. Computing Teacher, 15(3), 12–15.

Battista, M., & Clements, D. (1988). Logo-based elementary school geometry curriculum. Arithmetic Teacher, 36(3), 11–17

Bransford, J., & Stein, B. (1984). The IDEAL problem solver. New York: Freeman.

Clements, D., & Gullo, D. (1984). Effects of computer programming on young children’s cognition. Journal of Educational Psychology, 76, 1051–1058.

Emihovich, C., & Miller, G. (1988). Talking to the turtle: A discourse analysis of Logo instruction. Discourse Processes, 11, 183–201.

Hayes, J., & Simon, H. (1974). Understanding written problem instructions. In L. Gregg (Ed.), Knowledge and cognition. Hillsdale, NJ: Erlbaum.

Keller, J. (1990). Characteristics of Logo instruction promoting transfer of learning: A research review. Journal of Research on Computing in Education, 23, 55–71.

Kurland, D., Clement, C., Mawby, R., & Pea, R. (1987). Mapping the cognitive demands of learning to program. In R. Pea & K. Sheingold (Eds.), Mirrors of minds: Patterns of experience in educational computer (pp. 103–127). Norwood, NJ: Ablex.

Littlefield, J., Delclos, V., Lever, S., Clayton, K., Bransford, J., & Franks, J. (1988). Learning LOGO: Method of teaching, transfer of general skill, and attitudes toward school and computers. In R. Mayer (Ed.), Teaching and learning computer programming (pp. 111–135). Hillsdale, NJ: Erlbaum.

Muller, J. (1997). The great LOGO adventure: Discovering LOGO on and off the computer. Madison, AL: Doone Publications.

Papert, S. (1980). Mindstorms: Children, computers and powerful ideas. New York: Basic Books.

Pea, R., & Kurland, D. (1987b). On the cognitive benefits of learning computer programming. In R. Pea & K. Sheingold (eds.), Mirrors of minds: Patterns of experience in educational computing (pp. 147-177). Norwood, NJ: Ablex.

Rosen, M. (1993). Lego meets LOGO. In T. Cannings & L. Finkel (Eds.), The technology age classroom (pp. 226– 230). Wilsonville, OR: Franklin, Beedle & Associates.

Salomon, G., & Perkins, D. (1987). Transfer of cognitive skills from programming: When and how? Journal of Educational Computing Research, 3, 149-169.

Shimabukuro, G. (1989). A class act: Junior high students, LEGO and LOGO. Computing Teacher, 16(5), 37–39.

Smith, D., & Cypher, A. (1999). Making programming easier for children. In A. Druin (Ed.), The design of children’s technology (pp. 201–221). San Mateo, CA: Kaufmann.

Yoder, S. (1992, March). 1/3+1/3+1/3=1 . . . Right? Computing Teacher, 38–40

Yusuf, M. (1995). The effects of LOGO-based instruction. Journal of Educational Computing Research, 12(4), 335–362.