24.5 Computer programming languages as cognitive tools

24.5.1 What Are Computer Programming Languages?

Computers are essentially high-speed calculators that are able only to accept and move around electronic signals. Their power and any intelligence that can be ascribed to them are implicit in the programs that operate them. Many different kinds of programs can be entered into computers to control what they do. At the lowest level, many of a computer's electronic components (the ROM and EPROM chips) have "hard-wired" programs that are encoded into the logic of the physical connections themselves. The electronic programs that actually drive the computer describe, memory locations to which combinations of high and low voltage charges (zeroes and ones) should be moved or ways to manipulate the charges that correspond to larger numbers that represent higher-level information. Programmers use higher-level assembly language programs to activate these machine language programs. Assembly language programs are comprised of low-level commands to move information around the machine.

Programming most often refers to the use of higher-level, procedural languages, like BASIC and Pascal. These languages are the ones that are most often taught to students in schools. Computer programming languages consist of sets of keywords and commands that are interpreted or compiled by other assembly language programs through the programming language editors into machine code that ultimately "runs" the computer. Combinations of commands define programming structures. Procedural languages have only three major types of programming structures: list, repetition, .and decision (selection) structures. List structures describe linear sequences of operations that are performed by the computer every time the list routine is invoked. Repetition structures (loops) are sets of operations that are repeated by the computer. The same set of operations may be repeated a specific number of times or until a certain numerical state exists, or while a certain numerical state exists. Repetition structures are often embedded within each other, so that loops of operations run inside other loops, which run inside still other loops. Selection structures describe the causal, decision-making operations in a program. These statements are typically written in IF-THEN-ELSE format; that is, if a specific conditions exists, do one sequence of operations. If another condition exists, do another sequence of operations. If neither condition exists (ELSE), do something else. Decisions can be combined to provide complex options. There are many ways these structures can be written and combined in order to solve computational problems.

Selecting and sequencing programming commands in order to solve some computational problem is a very complex process. Taylor (199 1) defines the process of computer programming in five steps: problem definition, algorithm design, code writing, debugging, and documentation. According to Pea and Kurland (1984), programming consists of similar subtasks, such as understanding the problem, designing and planning the program, coding the program, and comprehending and debugging the program.

For many years, people have theorized that learning to program is an activity that develops higher-order thinking skills (Taylor, 1980). The languages that have most often been taught to learners in American schools in hopes of developing reasoning and thinking skills are BASIC, Pascal, and LOGO. A microcomputer version of the artificial intelligence (AI) language, Prolog, is often taught in European schools.

24.5.1.1. BASIC. The development of BASIC (Beginner's All-purpose Symbolic Instruction Code) accompanied the rapid growth of computing in the 1960s. It was developed at Dartmouth University as a standard, introductory procedural programming language. Although very popular in the "computer literacy" movement of the 1980s, BASIC has been phased out of many educational programs in recent years. The primary complaint about BASIC is its inherently unstructured nature. BASIC code is written in the numerical sequence in which it will be executed. The flow of any BASIC program is controlled by GOTO statements that refer to the line number of the statement to be executed. Unless a careful and very structured approach to writing BASIC code is used, the order of operations can become very confused through unrestricted use of flow control statements. Newer versions of BASIC are inherently more structured and powerful.

24.5.1.2. Pascal. Unlike BASIC, Pascal is an inherently structured programming language that requires that programmers identify all of the variables, procedures, and functions that they intend to use in the program. The purpose of this requirement is to produce more organized, better-structured programs. Since its introduction in 1971, Pascal, named for the French mathematician, has become the language that is often taught first to computer science students. Pascal, like LOGO (described below), enables Programmers to define subprograms, including functions and Procedures, and then to call them whenever they are needed. This feature avoids having to repeat sections of the code within the program. Another advantage of Pascal is the flexibility of its control structures, which are used to define subtasks or program modules. Repetition structures, such as REPEAT-UNTIL and WHILE-SO, and selections structures, such as IF-THEN-ELSE and CASE, are straightforward and easy to use.

24-5.1-3. LOGO. LOGO is a simplified language created at the Massachusetts Institute of Technology (MIT) by Seymour Papert (1980) to engage children in the construction of microworlds. The part of the LOGO language that is used most often consists of geometric commands that are sent to a turtlelike object on the computer screen to draw objects on the screen. (A cybernetic turtle that moves along the floor and draws onto a piece of paper under the turtle is also sometimes used in classrooms with very young children.) Children use LOGO to "teach" the turtle to draw objects by writing Pascal-like procedures. Children learn to combine those procedures into larger procedures that draw more complex scenes containing those objects. The syntax of the language is simplified enough to allow learners to explore and experiment with creating scenes (called microworlds). The main ideas that are fostered by LOGO are procedures, nesting procedures, and recursion (having a procedure call itself). ,

In addition to turtle graphics, LOGO contains a set of list-processing commands that are equivalent to the Al language, LISP. Learners use these commands and the procedures acquired through turtle graphics to create poems or conversations with each other. Although LOGO is syntactically much easier than BASIC or Pascal, it still requires the understanding of very abstract concepts, such as variables, procedures, and recursion. A more recent development is the integration of LOGO, the programming language, with Lego, the toy building blocks. With LOGO-Lego, children build physical structures (e.g., a windmill) with Lego pieces and activate them with LOGO commands.

24.5.1.4. Prolog. Prolog (PROgramming in LOGic) was developed as an artificial-intelligence language for solving problems that involve objects and their relationships stated in terms of declarative logic. 7 hat is why it is so often used to write programs representing human knowledge structures. It is interactive and conversational. Programming in Prolog consists of declaring facts about objects and their relationships, defining rules about those objects and relationships (like inheritance), and asking questions about those objects and relationships.

Micro-Prolog (Prolog for microcomputers) programs are made up of sentences that state objects and their relationships. These objects and relationships are added to the program individually. Prolog allows the user to ask true-false and search questions about the database that has been developed. The power of Prolog. is afforded by its use of conditional, rule-based logic. Using simple building blocks, Prolog can be used to develop complex databases of information. What makes Prolog especially useful as a cognitive tool is its focus on knowledge representation.

24.5.1.5. Other Languages. Other procedural languages, like C and its derivatives, and Al languages like LISP, are also taught to students, though certainly not with the degree of regularity of those described above. The trends in programming include a diminished interest in procedural languages like BASIC and Pascal, and a translation of those and other procedural languages into "object-oriented programming systems" (OOPS). Rather than procedures and functions as sequences of actions, in OOPS, these are treated as reusable objects that can be combined like building blocks to construct a program. The program or the user sends messages to these objects. These objects respond according to the message sent. The building block approach is especially important in defining screen objects like scroll bars, windows, buttons, icons, and menus in window-type environments that comprise the user interface to the program. So when the user points and clicks at an icon, the icon object responds depending on its location and program. Languages like Smalltalk were originally designed as OOPS environments; however, object-oriented versions of procedural languages like BASIC (Microsoft's Visual BASIC), Pascal (Borland's Delphi), and C (Borland's C++) are preferred by most programmers today. OOPS languages can help to promote critical thinking as well as programming efficiency because of their inherent structure and more clearly defined interfaces and usage declarations.

OOPS may encourage more effective collaboration in defining interfaces, and the skills students learn may be more marketable since most businesses are using object-oriented versions of popular programming languages. Probably the most commonly used object-oriented language in schools is HyperTalk, the scripting language that is used with HyperCard, though object-oriented versions of most computer languages are now available.

24.5.2 How Are Computer Programming Languages Used as Cognitive Tools?

Proponents of programming have argued that learning to program requires that learners think in an organized, systematic way about the problems they are attempting to solve, and that the thinking skills acquired while learning to program transfer to other nonprogramming problem situations. Before considering the cognitive effects of programming, we briefly review research on the cognitive requirements of learning to program.

Programming is a complex task. It involves many aspects of problem solving, such as problem decomposition, selecting appropriate information, assigning variables, identifying plausible solutions, applying programming structures, debugging code, and so on. McCoy (1990) showed that learning to program requires five skills: general strategy, planning, logical thinking, variables, and debugging.

Complex skills like these require different forms of intelligence. Cafolla (1987-88) found that the strongest predictors of learning to program were verbal reasoning, level of cognitive development, and mathematical reasoning. Additionally, analogical reasoning ability is strongly related to the ability to write subprocedures among high school students learning to program in LOGO (Clement, Kurland, Mawby & Pea, 1986). Computer programming is also dependent on various cognitive controls and styles of learners (Jonassen & Grabowski, 1993). Students who are field independent perform better in computer programming classes than field-dependent learners; i.e., field-independent students are more analytical thinkers. In fact, field independence, logical reasoning, and direction-following skills were found to be highly correlated with programming skills among college students (Foreman, 1988).

Computer programming is also subject to developmental differences among learners. Fourth-graders were far less able than older students to understand and use variables because of the level of abstraction, the dynamic nature of the values of variables, the degree of complexity in using variables, and the level of reasoning required (Nachmias, 1986). This means that computer programming may be introduced at the upper elementary level, but that abstract concepts in programming must wait until later. Even college students experience difficulties in learning to program. Among undergraduates, Fischer (1986) found that programming skill in a course was highly correlated to formal operational reasoning (from Piaget), especially the classification of abstract concepts, control structures, and top down programming. Formal operational reasoning ability is also essential for the use of some of the other cognitive tools, especially expert systems.

Computer programming has long been associated with mathematics. It has often been assumed that skilled mathematicians make competent programmers, because the same kinds of logical reasoning are required. This is partially true; however, programming computers is more directly related to analytical reasoning. Chin and Zecker (1985) found that programming ability was not, as expected, related to math ability, but rather internal locus of control was a much better predictor. On the other hand, Nowaczyk (1983) found that mathematics and English course performance, previous computer experience, and logic and algebraic word problem performance were significantly correlated to programming performance among college students. Being able to break down problems and search and select relevant information and solutions to the problem are most important for learners. Many people, including scientists, engineers, and mathematicians, are analytic, while many people are not. Most people can learn to function more analytically, but it is not easy. Programming is difficult because it requires thinking that learners are not often called on to perform.

24.5.3 What Learning Outcomes Result from Using Computer Programming Languages as Cognitive Tools?

Most of the educational research on computer programming has assessed how much the logical reasoning required to program computers generalizes or transfers to other nonprogramming problems. The assumptions of most of this research is that the analytic thinking required to program will naturally make learners better problem solvers in other settings. Learning to program has been shown to have a variety of effects on learners' thinking in different settings, although the research findings are inconsistent. Ahmed (1992) reviewed 21 studies and found that half of the studies showed some positive effects of learning to program; half did not. Much of this research focuses on the cognitive residue from learning to program. Some studies found positive correlations. Liao and Bright (199 1) conducted a metaanalysis of research on the effects of computer programming on cognitive outcomes and found that the large majority of studies concluded that students who learned to program scored higher on various cognitive tests than those who did not, although the differences were not large. For example, students who learned six weeks of BASIC performed better on mathematical-thinking skills, including programming ability, generalization, and understanding variables, than the control group (Oprea, 1988). This was especially true for shorter programming courses rather than longer ones and for learning LOGO rather than BASIC or Pascal.

Most of the cognitive outcomes research was conducted on learning to use LOGO for building microworlds. While LOGO was designed as an experimental tool for building microworlds, it also uses a procedural programming language. The cognitive residue from these experiences varies. Clements (1985) conducted a thorough review of LOGO research and concluded that almost all children can learn to program in LOGO. LOGO is especially effective in encouraging prosocial. behavior, positive self-image, and positive attitudes toward learning. However, the cognitive gains from LOGO apply mainly to LOGO-related teaming. Clements also found that programming does facilitate some problem-solving behaviors, and LOGO may facilitate the development of some cognitive skills such as classifying, seriating, and conserving. Clements and Gullo (1984) found that learning to program in LOGO improved 6-year-olds' reflectivity, divergent thinking, and metacognitive ability, when compared to a group receiving computer-assisted instruction. After one year of LOGO experience, fifth- and sixth-graders performed better on LOGO-related problem solving, general problem solving, and the mental rotation of geometric figures, a spatial reasoning ability (Miller, Kelly & Kelly, 1988). However, Pea and Kurland (1984) found that LOGO programmers were no better at planning skills than control group students, and no differences in the ability to visualize and draw designs resulted from learning to program among fourth- and fifth-graders (Williamson & Ginther, 1992). Kurland, Pea, Clement, and Mawby (1986) found that after studying programming for a year, LOGO programming experience did not transfer to other domains with similar properties. Jansson (1987) conducted three studies that showed no benefit of learning to program on conditional reasoning tasks.

The equivocal results of learning to use LOGO is partially a result of the teaching methods used with LOGO. Although it was intended to be used as an experiential, discovery-learning tool, too often LOGO was taught by direct teaching. Swan and Black (1990) found that explicitly teaching problem-solving strategies and applying them to solve problems in LOGO was more effective than providing only LOGO programming practice, teaching the strategies with concrete manipulables, or traditional problem-solving instruction. That is, learning to program is facilitated by practice in programming. But programming was not the primary purpose of LOGO. Harel (199 1) maintains that one reason for the failure of LOGO skills to transfer to other domains is that teachers have often treated "LOGO as an object of knowledge in itself, rather than as a tool for acquiring other teaming" (p. 37). Harel also complains that in most of the negative studies of the effects of learning LOGO, "children did not have time to learn LOGO in any depth" (p. 84). However, even if the sustained study of programming can be demonstrated to improve the ability of students to perform on some critical-thinking tests, the gains may not be worth the time and effort required to learn to program.

Harel's (1991) Instructional Software Design Project (ISDP) represents a unique effort to use programming as a cognitive tool within a software design context. Harel claims that the ISDP combines Papert's "constructionist" theory (1993) with Perkins "knowledge as design" pedagogy (1986). In the ISDP research study conducted by Harel for her doctoral dissertation, 17 fourth-grade students used LOGO for a semester to create software products that were intended to teach fractions to third-grade students. Her study combined quantitative, qualitative, and comparative research methods to investigate the effects of this "learners as designers" approach.

Harel (1991) reports that the fourth-grade students spent an average of 70 hours working on their software design projects. While the particular nature of the software projects was left open, there were two important requirements for students in the program: (1) writing in a "Designer's Notebook" every day and (2) attending periodic "Focus Sessions" about software design, LOGO programming, and fractions. A teacher and the researcher were available at all times to help the students with their design efforts. Although each of the students produced a separate software product, collaboration among the students was encouraged.

Harel compared the differences in LOGO skills and fractions knowledge between the 17 students in the ISDP and 34 other students in two classes who were studying LOGO and fractions via "a traditional teaching method" (p. 26.3). No significant differences were found in pretests among the three classes. Harel reports that "In general, the 17 children of the experimental class did better than the other 34 children on all posttests (fractions and LOGO)" (p. 272). Although not all differences were statistically significant, the general trend was quite positive in terms of specific learning outcomes as measured by multiple measures, including paper-and-pencil tests, computer exercises, videotaped observations, and interviews.

The major part of Harel's (1991) study is a detailed description of the activities and metacognition of one student, "Debbie," over the 4-month period of the project. Harel wrote that her detailed analysis of Debbie's work as well as her observations of other students indicated that "Throughout ISDP, the students were constantly involved in metacognitive acts: learning by explaining, creating, and discussing knowledge representations, finding design strategies, and reflecting on all of the above" (p, 359). In addition to positive cognitive effects in terms of metacognition, Harel concluded that the ISDP students acquired enhanced cognitive flexibility, better control over their problem solving, and greater confidence in their thinking abilities. She notes, however, that the study did not include any direct measures of thinking skills, but her own interpretations of the students' metacognition and problem-solving processes were based on observations and analysis of documentation such as their Designer's Notebooks.

Thinking is always somewhat dependent on the nature of the problem or the content. Programming clearly requires learners to think deeply. However, this deep thinking does not necessarily transfer to other content or problems as much as educational experiences that are focused on content-dependent problem-solving skills. The transfer of programming logic could probably be enhanced by direct instruction that models how to apply programming skills to other problems rather than teaching the language and only later applying it to solving problems. Harel's (1991) study provides an exemplary approach to the integration of learning programming into a design and problem-solving environment. Kafai's (1995, 1996) studies of students using LOGO to create games for other students is a creative continuation of the research carried out by Harel. Interestingly, Kafai found that the students designing games using LOGO did not perform as well as a control group of students using LOGO to design instruction in the manner used in Harel's ISDP

In light of the results described above, a question rises: Why have the results of learning to program been so inconsistent and generally disappointing to the advocates of this approach? The answer may be found in both the nature of the cognitive tools themselves and the different approaches to applying them. Some cognitive tools such as databases, spreadsheets, and even hypermedia/multimedia authoring systems described later in this chapter share a common set of attributes (Jonassen, 1996). They are readily available, generic applications; they are affordable; they are used to represent knowledge in content domains; they are applicable across different subject domains; they engage critical thinking in learners; they facilitate transfer of learning; they are simple, powerful formalisms; and they are reasonably easy to learn.

This latter criterion is the most problematic for computer programming. Programming in most computer languages requires learning as many as 100 different commands, knowing when and how to embed those commands into programming structures, and, most problematic and especially time consuming, a lot of syntax that constrains both of these. After a semester-long Pascal course in high school, students made errors using virtually every Pascal construction (Sleeman, Putnam, Baxter & Kuspa, 1986). Punctuation, spaces, order of operations, and a host of other syntactical requirements add hundreds and even thousands of rules that must be learned and faithfully used before programs run without error, Unlike traditional human languages, where the meaning of speech or writing can usually be determined regardless of misspellings, placement, usage errors, computers are unforgiving. A single error ca prevent a program from running, despite the fact that man beginning programming students believe that computer have the reasoning power of human beings in comprehending language (Sleeman et al., 1986).

The primary conclusion of programming research is that the cognitive overhead (the amount of mental effort required to use programming languages) mitigates the ability of the learner to use computer programming as an easy and effective means for solving problems or representing what the learner knows, which is the goal of using cognitive tools in the first place. After 2 years of programming instruction, many students have only rudimentary understanding of programming ideas (Kurland, Pea, Clement & Mawby, 1986). Until programming skills become automated (which requires years of experience to occur), more effort is required to program the computer than to represent the knowledge or solve the problem. There is little doubt, however, that computer programming is among the most flexible and powerful of the cognitive tools for those who are skilled programmers. It is the requirement of these complex skills that calls into question the utility of computer programming as a cognitive tool.

This argument against programming as a robust cognitive tool is being mitigated by newer computer-programming environments, like Think Pascal and Think C, that have syntax error detection and correction routines built in. These routines identify syntax errors when they are made, thereby reducing the cognitive load and responsibilities on the learner. They also automatically format the code by indenting where necessary. Newer programming languages, such as Visual BASIC, Delphi, and Visual C, provide even more sophisticated code-generating routines, so that the programmer needs only to identify the program structure and the variables, and the environment is able to generate the necessary programming code. These languages are especially effective for producing user interfaces by automating the creation dialog boxes, windows, and so on. These types of environments represent major improvements in simplifying the programming process, allowing the programmer to act as a designer who focuses on the problem-solving task more than on writing code. However, to what extent does this replacement affect the thinking that the programmer is required to do? These environments definitely enhance code generation, but do they support critical thinking? Additional research must be done before we can answer this question.

In addition to differences in the nature of various cognitive tools, the approach to using them obviously has a major impact on their effectiveness. When cognitive tools become objects of study in and of themselves, as seems to be the case in many studies of the effects of programming, they cannot be expected to have major effects on higher-order thinking skills. However, where these tools are applied to meaningful and personally rewarding tasks, they may have much more impressive results. Despite the cognitive demands of learning programming, there may be nothing inherently wrong in the use of programming as cognitive tools if the context in which programming is learned captures the attention, intrinsic motivation, and commitment of learners.