ED 249 919

AUTHORTITLE

INSTITUTION

SPONS AGENCY

PUB: DATE;CONTRACT

Writ

PUS TYPE

.

EDRS PRICEDESCRIPTORS

DOCUMENT RESUME

IR 011 338

Pea, Roy D.; Kurland, D. MidianOn the Cognitive Effects of Learning ComputerProgramming: A Critical Look. Technical Report No9.

'MAStreet Coll. of Education, New York, NY. Center

or .Children and Technology. r

National Inst. of Education (ED); Washington, DC.;Spencer Foundation, Chicago, ill.Jan 84400-83-001648p.; For related documents, see IR 011 340, IR 011353, and IR 011 359.'Information Analyses (070) -- Viewpoints (120)

1001 Plus Postage. PC Not Available from EDRS.Cognitive Ability; *COgnitift Processes; *ComputerAssisted Instruction; Literature Reviews;*Programers; *Programing; *Skill Development

ABSTRACTThis paper provides an historical and empirical

critique of the claim that learning to program will promote thedevelopment of general higher mental functions. A developmentalperspective on,learning to program is provided which incorporatescognitive science studies of mental activities involved inprogramming, AncUlighlights the importance of programming contexts,instructional contexts, and a student's relevant background knowledgeand reasoning skills for the task of learning to ibiogram. Thefollowing topics are discussed: claims for cognitive effects oflearning to program; the develoemental role of contexts in learningto, program; the programming environment; the instructionalenvironment; what constitutes skilled" programming; levels ofprogramming skill, development; cognitive constraints on.learning toprogram; and evidence for cognitive effects of programming. Types oftransfer outcomes expected from each of the different levels ofprogramming skill development are described, and a concludingstatement and a 14-page list of references are included.(Author/THC)

***********************************************************************Reproductions supplied by EDRS are the best that can be made

from the original document.***********************************************************************

atompiummorroteniumoss-111/4710NAL INSTITUTE Of IDUCATKIN

-EDUCATIONAL RESOURCES INFORMATIONCENTER IERICIifhis document has been reProduced M

teceivsd from the potion or corperketicts - ;

Cr 04101nAtilva it...

t 1 *nor ewe's have Men mode to 11111NOve :

:1"111 reproduction quality.

Crik : e Points ol vieve or opetions stated in this dug: )',

110I nueswile nemsent OMAN NIE ,

' iiosonot potco.,,, . :_ . ,' ..___.

N I

"PERMISSION TO REPRODUCE THISMATERIAL IN MICROFICHE ONLYHAS BEEN GRANTED BY

TO THE EDUCATIONAL RESOURCESINFORMATION GENTER (ERIC),"

\'{ On the Cognitive Effects of LearningComputer Programming: A Critical Look

Roy D. Pea and D. Midian Kurland

Teci,nical Report No. 9

January 1984

Or, n the Cognitive Effects of LearningComputer Programming: A Critical Look

Roy D. Pea and D. Midian Kurland

Technical Report No. 9

January 1984

CENTER FOR CHILDREN AND TECHNOLOGYBank Street College of Education610 West 112th StreetNew York, NY 10025

ON THE COGNITIVE EFFECTS OF LEARNINGCOMPUTER PROGRAMMING*,**

Roy D. Pea. and D. Midian Kurland

Revolutionary changes are taking place in education, in content aswell as method. Widespread computer access by schools is at theheart of these changes. Throughout the_.. world, but particularly inthe United States, educators are using computers for learning activi-ties across the curriculUM and are even designing their own software.But virtually all educators are as anxious and uncertain about thesechanges and the directions to take as 'they are optiniiittic about theirultimate effects. They ask: "Now that this admittedly pOwerfulsymbolic device is in our schools, what should we do with it?"

We believe that educators and social scientists are at a critical water-shed in American education. Important new opportunities abound forresearch and development work that can influence directly the qualityof education. Hard questions are emerging about the design ofeducational activities that integrate the computer with other media.The volatile atmosphere of choices for schools (and parents), as newhardware and software appear daily, calls for principles and knowl-edge educators can use, derived from systematic empirical studies inlaboratories and classrooms, of how children learn with these newinformation technologies. We also need theoretical debates on the aimsand priorities for education in an information age. We believe that adevelopmental approach to the understanding of information technolo-gies will be required that incorporates the new insights of cognitivescience and will guide both research on and design of computer-based

dmiImlalilmINN.111.01111..

*Revised version to appear in Nev Ideas in Psychology, Elms-ford, NY: Pergamon Press, May 1983 [revisions made in October19831.

**We would like to acknowledge with thanks the Spencer Founda-tion and the National Institute of Education (Contract #400-83-0016)for supporting the research reported here, and for providing theopportunity to write this essay. The opinions expressed do natnecessarily reflect the position or policy of these institutions and noofficial endorsement should be inferred. John Broughton, Jan Haw-kins, Karen Sheingold, Ben Shneiderman, and a group of anonymousreviewers provided very useful critical discussions of the data andissues covered in this report.

.

learning environments. This developmental cognitive science disci-pline would merge theory and practice to dovetail the symbolic powersof human thinking with those of the computer in the service of humandevelopment.

As described in this essay, our goals are considerably more modestbut, nonetheless, a timely subtask of the larger enterprise. Our aimis to examine two widespread beliefs about the mental activities en-gaged by programming a computer and their expected cognitive andeducational benefits. The two beliefs are polar opposites and neitheris acceptable. Together, they express the predominant tendencies inthinking about learning to program today.

The first belief is linked to an atomistic, behaviorist tradition thatviews learning narrowly. This is the traditional and deeply engrainedidea that learning is simply an accumulation of relatively autonomousfacts. In this .view, what one le-rns when learning to program is thevocabulary of commands (priori' _yes) and syntactic rules for con-structing acceptable arrangements of commands. This belief underliesmost programming instruction. Its other facet is that what one learnswhen learning programming is just a programming language.

The contrasting belief, in part a reaction to the first belief, is thatthrough learning to program; children are learning much more thanprogramming "facts." It is being claimed' 'that children will acquirehigher cognitive skills such as planning abilities, problem-solvingheuristics, and reflectiveness on the revisionary character of theproblem-solving process itself. This belief, although new in itsapplication to this domain, is an old idea in a new costume. It isbased on a common, albeit extreme, assumption about learning- -thatspontaneous experience with a powerful symbolic system will havebeneficial cognitive consequences, especially for higher order cogni-tive skills. Similar arguments have been offered in centuries past formathematics, logic, writing systems, and Latin (see Bruner, 1966;Cole & Griffin, 1980; Goody, 1977; Olson, 1976; Ong, 1982; Vygot-sky, 1978).

M

The intuitively plausible claims for the cognitive benefits of pro-gramming have broadened in scope and in public attention. Al-though, as yet, there is no, evidence to support these claims, theirpresumed validity is affecting important decisions in public educationand leading to high expectations for outcomes of programming in theschool and home. In the current climate of uncritical optimism aboutthe potential cognitive benefits of learning to program, we run therisk of having the naive "technoromantic" ideas become entrenched inthe school curriculum by affirmation rather than by empirical verifi-cation through a cyclic process of research and development. At the

2

5

e.

pre-high school level, programming is being taught primarily becauseof its assumed impact on higher cognitive skills, not because profi-ciency in programming is itself an educational goal. This assumptiontakes on added significance since several million precollege-age chil-dren in the United States are already receiving instruction in com-puter programming each year, and France has recently made program-ming compulsory in .their precollege curriculum, on a par with mathe-matics and native language studies.

With the rapid rise in the teaching of programming, it has becomecritical for decision ,makers in education to understand how program-ming is learned, what the cognitive outcomes may be of learning toprogram, what levels of programming skill may be required to obtaindifferent types of outcomes, and what the relationships are betweenthe cognitive constraints on learning to program and its cognitiveconsequences. Research directly addressing these questions is inits infancy.

Throughout our paper, we will highlight major issues and fundamentalcomplexities for researchers in designing studies responsive to thesecritical questions. We discuss these issues in terms of a hybriddevelopmental framework that incorporates cognitive science anddevelopmental psychology, and review relevant research in cognitivescience and its cognate disciplines. This synthesis recognizes theinadequacies of either an extreme knowledge-building account oflearning to program, or the naive technoromanticism that postulatesspontaneous higher order cognitive skills asoutcomes of programmingexperiences. Although claims about the spontaneous cognitive impactof programming have an intuitive appeal, we show them to be miti-gated by consideration of factors involved in learning and develop-ment. We also demonstrate how, in practice, the fact-learning ap-proach to programming often leads to incomplete programming skills.Cognitive studies of what expert programmers know, the level of thestudent's programming skills, the goals and purposes of those learn-ing to program, and the general difficulty of transferring powerfulideas across domains of knowledg.. all contribute to our rejection ofthese two views. Programming, in the classroom ma fundamentallyalter the ways in which learning and cognitive development proceed.But we must examine whether such bold claims find, or are likely tofind, empirical sUpport.

Throughout our analysis of these issues, we have felt that a develop-mental perspective that incorporates the seminal work in the lastdecade of the interdisciplinary field of cognitive science will illuminateour understanding of the potentialities of information technologies foradvancing human cognition. Fundamental contributions to thinkingabout and concretely establishing the educational roles of information

63

technologies could be gained from the synthesis of these two impor-tant theoretical traditions.

Developmental theorists such as Piaget and Inhelder (1969), Werner(1957), ant Vygotsky (1978) have provided accounts of developmentalprocesses with profound implications for the role of technologies ineducation. kIn all these views, cognitive development consists not ofan accumulation of facts, but of a series of progressive reorganiza-tions of knowledge driven by the child's active engagement withphysical and social environments. In these views, learning (i.e., theaccumulation of new knowledge) is important for driving the develop-mental process but, at the same time, is mediated by the currentdevelopmental capabilities of the learner.

During the last decade, researchers in the constituent disciplines ofcognitive science--cognitive psychology, computer science, linguistics,anthropology, and philosophy - -have begun intensive collaborativeresearch projects (e.g., Gentner & Stevens, 1983; Greeno, Glaser &Newell, 1983; Norman, 1981). The combination of careful analysis ofcognitive processes and the techniques of computer simulation has ledto important new insights into the nature of mental representations,problem-solving processes, self-knowledge, and cognitive change.Cognitive science has revealed the enormous importance of extensive,highly structured domain-specific knowledge and the difficulty ofdeveloping, general-purpose, problem-solving strategies, that crosscutdifferent knowledge domains. In addition, within particular domains,cognitive science research has been able to specify in great detail thenaive "mental models" held by novices, such as Aristotelian beliefsabout objects in motion, which are often very resistant to changethrough spontaneous world experience (Gentner & Stevens, 1983).

Cognitive science shares with the older tradition of developmentalpsychology a concern with how new learning must be integrated withprior knowledge, but it transcends earlier work in analyzing problemsolving and learning processes for specific knowledge domains, andfinds little role for general structural principles invoking "stages."

For a student interacting with a programming environment, for ex-ample, a developmental perspective would indicate the importance ofstudying how these students' current knowledge of the computeraystem is organized, how they regulate and monitor their interactionswith it, and how their knowledge and executive routines affect theease or pace of acquisition of abilities to use new programming con-structs. It would also investigate the students' exploration of thesystem, and the ways in which they are able to assimilate it into theircurrent level of understanding and to appropriate it in terms of theirown purposes, including play and competition. Learning to use the

4 7

programming language may require successive developmental reorgani-zations not only of the students' naive understanding of the languagebeing learned, but of the computer system as a whole. Complexcognitive changes are unlikely to occur through either spontaneousexploration or explicit instruction alone, since students must beengaged in the task in order to interpret the new concepts. Thisperspective suggests that, rather than engaging in the currentargument over global questions such as which computer language isbest for children, we would do better to ask how we can organizelearning experiences so that in the course of learning to program,students are confronted with new ideas and have opportunities tobuild them into their own understanding of the computer system andcomputational concepts.

In complementary terms, cognitive science raises such importantquestions ass How can common systematic misconceptions in particulardomains of knowledge be diagnosed and remediated through eitherinformal or formal learning activities? For example, what does astudent specifically need to know in order to comprehend and useexpert strategies in designing a computer program? What componentmental processes are engaged in programming activities?

The synthesis of developmental cognitive science focuses on diagnos-ing the mental models and mental processes that children as well asadult novices bring to understanding computer programming, sincethese models and processes serve as the basis for understandingtransformations of their systems of knowledge as they learn. Beyondthe typically agenetic cognitive science, a developMetital cognitivescience would asks How are the various component mental processesinvolved I:. expert programming constructed and reconfiguredthroughout ontogenesis, and accessed and organized during problem-solving episodes? Through what processes of reorganization does anexisting system of thought become more highly developed? Throughwhat learning activities in what kinds of environments does the noviceprogrammer develop into an expert? Developmental cognitive scienceasks how the mind an i its ways of knowing are shaped, not only bybiological constraints or physical objects, but by the available culturalinterpretive systems of social and educational interaction. As weshall see, the currently available research is impoverished in responseto these questions, but current progress in understanding the devel-opment of mathematical and scientific thinking (reviewed, for example,in Siegler, 1983) leads us to be optimistic about the prospects forcomparable work on the psychology of programming.

The critique of the literature on learning to program that we presentbelow has been strongly influenced by this developmental cognitivescience perspective. We do not adopt the usual computer program-

5

ming perspective which assumes that all programming students areadults or have the same goals as mature learners. Instead, ourperspective is geared to the learning experiences and developmentaltransformations of the child or novice adult in interactive environ-ments. The kinds of preliminary questions we ask from this perspec-tive in addressing the question--What are the cognitive effects oflearning to program--lead us to draw on studies from diverse fieldsthat we see as relevant to a developmental cognitive science of pro-gramming. We have categorized them according to the followingtopics: What are the developmental roles of contexts in learning to

)program? What is skilled programming? What are the levels of pro-gr5mming skill development? What are the cognitive constraints onlearning to program? First, however, we will begin by examining the,bold claims about the effects of learning to program.

Claims for Cognitive Effects of Learning to Program

Current claims for the effects on thinking of learning to program arebest exemplified in the writings of Papert and Feurzeig on the Logoprogramming language (e.g., Feurzeig, Horwitz & Nickerson, 1981;Feurzeig, Papert, Bloom, Grant & Solomon, 1969; Goldstein & Papert,1977; Papert, 1972a, 1972b, 1980; Papert, Watt, DiSessa & Weir,1979), although such claims are not unique to Logo (see Minsky,1970).

Early claims. Two key catalysts underlie beliefs that programmingwill discipline thinking. The first is from artificial intelligence,where constructing programs that model the complexities of humancognition is viewed as a way of understanding that behavior. It iscontended that you learn more about your own thinking when youteach the computer to do something. Papert (1972a) draws the anal-ogy that, because of the necessarily explicit nature of programming,students will learn about problem-solving processes as they articulatethe assumptions and specify the steps of their problem-solving ap-proach. he second influence is the widespread assimilation of con-structivist epistemologies of learning, most familiar through Piaget'swork. Papert (1972a, 1980) has been an outspoken advocate of thePiagetian account of knowledge acquisition through self-guided prob-lem-solving experiences, and has extensively influenced conceptions ofthe benefits of learning programming through "a process that takesplace without deliberate or organized teaching" (1980, p. 8).

Ross and Howe (1981) have summarized Feurzeig et al.'s (1969) fourclaims for the expected cognitive benefits of learning programming.Initially, most outcomes were postulated for the development of mathe-matical thought:

69

ti

(1) that programming provides some justification for, andillustration of, formal mathematical rigour; (2) that pro-gramming encourages children to study mathematics throughexploratory activity; (3) that programming gives key in-sight into certain mathematical concepts; and (4) thatprogramming provides a context for problem solving, and alanguage with which the pupil may describe his own problemsolving. (p. 143)

Papert (1972b) argued for claims (2) through (4), noting that writingprograms of Logo turtle geometry is a

new piece of mathematics with the property that it allowsclear discussion and simple models of heuristics I such asdebugging] that are foggy and confusing for beginnerswhen presented in the context of more traditional elemen-tary mathematics lour emphasis].

He provides anecdotes of children "spontaneously discovering" phe-nomena such as the effects that varying numerical inputs to a pro-icedure,for drawing a spiral have on the spiral's shape. He concludesthat 'learning to make these "small discoveries" puts the child "closerto mathematics" than faultlessly learning new math concepts.

Recent claims. We find expanded claims for the cognitive benefits ofprogramming in a new generation of theoretical writings. In Mind-storms, Papert (1980) discusses the pedagogy surrounding Logo, andargues that cognitive benefits will emerge from taking "powerfulideas" inherent in programming (such as recursion and variables) in"mind-size bites" (e.g., procedures). One of his more dramaticclaims is that if children had the extensively different experiences inthinking about mathematics that -Logo allows, he sees "no reason todoubt that this difference could account for a gap of five years ormore between the ages at which conservation of number and combina-torial abilities are acquired" (p. 175). Here, Papert is referring toextensively replicated findings of a large age gap between the earlyconservation of number (near age 7) and later combinatorial abilities(e.g., constructing all possible pairings of a set of different coloredbeads, near age 12).

Feurzeig et al. (1981) provide the most extensive set of cognitiveoutcomes expected from learning to program. They argue that

the teaching of the set of concepts related to programmingcan be used to provide a natural foundation for the teach-ing of mathematics, and indeed for the notions and art oflogical and rigorous thinking in general.

10

Learning to program is expected to bring about seven fundamentalchanges in thought:

1. rigorous thinking, precise expression, recognized need tomake assumptions explicit (since computers run specific algorithms);

2. understanding of general concepts such as formal procedure,variable, function, and transformation (since these are used in pro-gramming);

3. greater facility with the art of "heuristics," explicit ap-proaches to problems useful for solving problems in jinx domain, suchas planning, finding a related problem, solving the problem by de-composing it into parts, etc. (since "programming provides highlymotivated models. for the principle heuristic concepts") ;

4. the general idea that "debugging" of errors is a "construc-tive and plannable activity" applicable to any kind of problem solving(since it is so integral to the interactive nature of the task of gettingprograms to run as intended);

5. the general idea that one can invent steal procedures suchas building blocks for gradually constructing solutions to large prob-lems (since programs composed. of procedures are encouraged inprogramming);

6. generally enhanced "self-coniciousness and literacy about theprocess of solving problems" (due to practice of

ofthe

process.. of problem .solvingl programming by means of the language,of programming concepts);

7. enhanced recognition that for domains beyond programmingthere is rarely a single "best" way to do something, but ratherdifferent ways that have comparative costs and benefits with respectto:specific goals (learning: the distinction between "process" and"product," as in Werner, 1937) .

The question of whether or not programming promotes the develop-ment of higher cognitive skills raises two central issues in devel-opmental cognitive science. First, is it reasonable to expect transferacross knowledge domains? Even adult thinkers are notorious fortheir difficulty in spontaneously recognizing connections between"problem isomorphs"problems of identical logical structure butdifferent surface form (Dick & Holyoak, 1980; Hayes & Simon, 1977;Simon & Hayes, 1976)and in applying strategies for problem solutiondeveloped in one context to new problem forms. With problems of"near" transfer so acute, the possibility of spontaneous transfer must

8 11

be viewed cautiously. In later discussions, we provicir a tentativedevelopmental model for thinking about relations between differenttypes of transfer beyond programming and different levels of pro-gramming skill.

The second and related question is whether intellectual activity isguided by general domain-independent problem-solving skills or by aconjunction of idiosyncratic domain-dependent problem-solving skills(Goldstein & Papert, 1977; Newell, 1980; Simon, 1980). An extensiveliterature on metamemory development indicates that the tasks used tomeasure the functioning of abstract thinking are inextricably linked tothe specific problems used to assess metacognition (e.g., Brown,1983a). As Ross and Howe (1981) note, "in most problem-solvingtasks, it is impossible to apply the supposed context-free skillswithout initially having essentially domain-specific knowledge." Withindomains, however, better performances by learners are commonlyaccompanied by reflection on the control of their own mental activities(Brown, Bransford & Ferrara, 1983).

The Developmental Role of Contexts in Learning to Program

For a developmentalist, there is a major problem pervading each ofthese characterizations of the effects on higher thinking skills ex-pected from learning to program. Programming serves as a "blackbox," an unanalyzed activity whose effects are presumed to irradiatethose who are exposed to it. But questions about the development ofprogramming skills require a breakdown of the skills into componentabilities, and studies of how specific aspects of programming skill areacquired. They require especially serious consideration of the devel-opmental roles played by the contexts interpenetrating the black box:the programming environment, the instructional environment, and therelevant understanding and, performance of the learner.

The question of the role of contexts in learning to program is complexbecause programming is not a unitary skill. Like reading, it iscomprised of a large number of abilities that interrelate with theorganization of the learner's knowledge base, memory and processingcapacities, repertoire of comprehension strategies, and general prob-lem-solving abilities such as comprehension monitoring, inferencing,and hypothesis generation. This lesson has been etched in high reliefby intensive efforts to develop artificial intelligence systems that"understand" natural language text (e.g., Schank, 1982; Schank &Abelson, 1977). Skilled reading also requires wide experience withdifferent genres (e.g., narrative, essays, poetry, debate) and withdifferent goals of reading (e.g., reading for gist, content, style).Just as reading is often equated with skill in decoding, so learning toprogram in schools is often equated with learning the vocabulary and

9

12

syntax of a programming language. But skilled programming, likereading, is complex and context-dependent, so we must begin tounpack the contexts in which programming is carried out and learned.

Environments in which children learn to read are usually overlookedbecause adequate environments (i.e., plenty of books, good lighting,picture dictionaries, good readers to help with hard words, vocabu-lary cards, phonics charts) are taken for granted. By contrast,good programming environments are not generally available to schools.Determining how children develop programming skills will not bepossible without due consideration of the programming environment inwhich learning and development takes place, and of how learningactivities are organized.

Programming Environment

The distinction between a programming language and a programmingenvironment is crucial. A programming language is a set of commandsand rules that instruct the computer to perform specified operations.The programming environment is the larger collection of software(operating systems and programming tools) and hardware (memory,disk storage, hard copy capability) available to the programmer. Itcan include an editor program to facilitate program writing, coderevising, and copying useful lines of code from one program to an-other; debugging aids; elaborate trace 'routines for following theprogram's flow of control; automatic documenters; cross-referenceutilities for keeping track of variables; and subroutine libraries.

Good programming environments (e.g., those most extensively devel-oped for working on large computers in Lisp and PL/I) make thecoding aspect of programming far more efficient, allowing the pro-gratnmer to concentrate on higher level issues of program design,efficiency, and elegance. In contrast, the programming environmentsprovided for today's school microcomputers are so impoverished (typi-cally consisting of only a crude editor and limited trace functions)that entering the code for a program and getting it to execute cor-rectly is the central problem.

Finally, despite vigorous arguments about the educkional superiorityof different programming languages, there are no data on whetherdifferent languages lead to significant differences in what childrenneed to know prior to programming, or what cognitive benefits theyderive from it. Although such differences among languages mayexist, they do not affect our point since they can be radically manip-ulated by restructuring the programming environment. Attention isbest directed to general issues about programming rather than tothose that are programming language specific.

10

:*4 A13

Instructional Environment

While features of the programming environment are important forlearning to program, how successfully a child will master programmingalso depends on the instructional environment and the way in whichresources such as computer access time and file storage are allocated.Each of these points concerns the context of cognitive activities,which we know from cognitive science and developmental psychologyto be critical to the level of performance achieved in cognitive tasks(for reviews, see Brown et al., 1983; LCHC, 1982).

Deciding how to introduce programming and assist students in learn-ing to proam is hampered today by the paucity of pedagogicaltheory. That current fact-learning approaches to programming in-struction are. inadequate has become apparent from studies of thekinds of conceptual errors made by novice programmers instructed inthat way. For example, novice adult programmers reveal deep misun-derstandings of programming concepts, and of how different lines ofprogramming code relate to one another in program organization(Sonar & Soloway,- 1982; Jeffries, 1982; Sheil, 1980, 1981a; Soloway,Sonar & Ehrlich, 1983; Soloway, Ehrlich, Sonar & Greenspan, 1982).As is to be expected from what they are taught, they know thevocabulary and syntax of their programming .langUage. Their misun-derstandings are much deeper (Jeffries, 1982), such as assuming thatall variables are global (when some may be specific to one proce-dure), and expecting that observing one pass ,thrOugh a loop allowsthem to predict what will happen on all subsequent passes (althoughthe outputs of programming statements Which test for certain condi-tions may change what will happen during any specific loop). Re-search by Mayer (1976) , Miller (1974), and Sime, Arblaster and Green(1977) has revealed that adult novice programmers' ,generally have a.difficult time with the flow of control concepts expressed by condi-tionals (for a review of these findings, see duBoulay, O'Shea & Monk,1981). These conceptual difficulties, even among professional pro-grammers, have been lamented by such programming polymaths andvisionaries. as Minsky (1970) and Floyd (1979) as due to problems withhow programming is taught. Too much focus is placed on low-levelform such as grammar, semantic rules, and some preestablifedalgorithms for solving classes of problems, while the pragmatics ofprogram design are left for students to discover for themselves.Interestingly, these complaints about writing programs are similar tothose voiced about how writing in general is taught (e.g., Scarda-malia & Bereiter, 1983).

We have observed that the conceptual problems of children learning toprogram are similar to those of adult novices. For example, in ourresearch with 8- to 12-year-old Logo programmers (Kurland & Pea,

1.4

11

1983), we find (through their think-aloud protocols and manual simu-lation of programs) that children frequently %dopt a systematic butmisguided conception of how control is passed between Logo proce-dures. Many children believe that placing the name of the executingprocedure within that procedure causes execution to loop backthrough the procedure, when in fact control is passed to a copy ofthe executing procedure. This procedure is then executed and, whenthat process is complete, control is passed back to the procedure thatlast called it. Children adopted mental models of flow of controlwnich worked for simple cases, such as programs consisting of onlyone procedure or tail recursive procedures, but which proved inade-quate when the programming goal required more complex programmingconstructions.

In other developmental studies of Logo programming skills (Pea,1983), even the 25% of .the children (8- and 9-year-olds; 11- and12-year-olds) who were extremely interested in learning programmingwrote programs that reached but a moderate level of sophisticationafter. approximately 50 hours of on-line programming experienceduring the year. Children's grasp of fundamental programmingconcepts, such as variables, tests, and recursion, and specific Logoprimitive commands such' as "REPEAT," was highly context-specific.For example, a child who had written a procedure using REPEATwhich repeatedly printed her name on the screen did not recognizethe applicability of REPEAT in a program to draw a square. Instead,the child redundantly wrote the same line-drawing procedure fourtimes. We expect,that carefully planned sequences of instruction' willbe important to ensure that programming knowledge is not "rigid"-(Werner, 1957), or' "welded" (Shif, 1969) to its context of firstlearning or predominant use. Such rigidity is a common finding forearly developmental levels in diverse domains (Brown et al., 1983).

In the National Assessment of Educational Progress survey of 250013-year-olds and 2500 17-year-olds during the 1977-1978 school year(NA EP, 1980), even among the small percentage who claimed to beable to program, "performance on flowchart reading exercises andsimple BASIC programs revealed very poor understanding of algorith-mic processes involving conditional branching" (cited by Anderson,1982, p. 14).

Educators often assume that adult programmers are not beleagueredby conceptual problems in their programming, but we have seen thatthey are. Once we recognize that programming by "intellectuallymature" adults is not characterized by error-free, routine perform-ances, we might better understand the difficulties encountered bychildren who devote only a small percentage of their school time tolearning to program.

1215

46

F17

These findings lead us to two central questions about programminginstruction, defined broadly to include the direct teaching providedby .educators as well as the individual advice, modelling, and use ofmetaphors with whiCh they support instruction and learning,- Howmuch and. what types of inistruction should be offered? How much.direct. ,instruction is best for children to learn programming is acontroversial .question-. (e.g.., Howe, 1981; Papert, 1980). At oneextreine., schools teach programming as they do any other subject,with. fact Sheets.. and tests; at the other,. they :provide minimal in-struction, encouraging children to explore possibilities, experiment,and create their own problems to solve. This second approach,popularized. by Papert (.198Q), argues that little overt instruction isnecessary' if the .programming language is sufficiently engaging andsimple to use, while at. the same time powerful. enough, for children todo projects they find meaningful. Though this.. discovery-learningperspective is" not universally shared, even by. Logo devotees (Howe,1981), it has had a pervaiive influence on the use of Logo byschools.

What type of instruction should be offered and, in the course ofprogramming skill development, when specific concepts, methods, andadvice should be introduced are also critical questions. Cogritivescience studies implicate two central factors. One is the currentmental model or system of knowledge that the student has available atthe time of instruction. A second is the goal-relevance of the prob-lem-solving activity required by the student.. On the first point,there are no careful studies of the success of different instructionalacts as a function of a student's level of understanding for program-ming akin to those carried out by Siegler (1983) .for such concepts astime, speed, and velocity. At a more general level, Mayer (1979,1981) has shown that a concrete conceptual model of a programmingsystem aids college students in learning BASIC by acting as anadvance organizer of the details of the language.. With the conceptualmodel, learners were able to assimilate the details of the programminglanguage to the model rather than needing to induce the model fromthe details.

On the second point, we would ask how compatible the teacher'sinstructional goals are with the children's goals and purposes inlearning programming. Recent developmental cognitive science andcross-cultural studies of cognition (e.g., Brown, 1982; Laboratory ofComparative Human Cognition, 1983) have shown that assessing taskperformance within a goal structure familiar to the person is neces-sary for determining the highest developmental level of an individual'sperformance. The goals of the programming activity need to becontexted for the child in terms of other meaningful and goal-directedactivities, connecting to everyday world affairs, to other aspects of

1613

the curriculum, or to both. Papert (1980) has described this as"syntonic" learning. For example, in , our studies, Logo classroomchildren found two contexts especially motivating; creating video-games and simulating conversations. The most intensive and 'advanc-ed programming efforts were in the service of goals such as these,thus reaffirming Dewey's (1900) point that new skills should serve asmore adequate means for achieving desired ends. A similar emphasisunderlies the successful use of electronic message and 7,ublishingsystems in classrooms ,(e.g., Black, Levin, Mehan & Quinn, 1982;Laboratory of Comparative Human Cognition, 1982). Embeddingcomputer programming activities of increasing cognitive complexity inchildren's goal structures may promote learning to program andsupport the transfer of what is llarned in programMing to problem-solving activities in other domains.1

Our point throughout this section has been that programming is nottaught by computers of programming languages but by teachers, withthe aid of, the supports of a programming environment. How effec-tively children of different ages and with different background knowl-edge learn programming will be contingent on the capabilities of theirteachers, the appropriateness of their learning activities to theircurrent level of understanding in programming, and the featuresavailable in their programming environment. Studies to date have notincorporated these considerations recogvized by a developmentalcognitive science perspective as central.

What is Skilled Programming?

How to define and assess the constellation of skills that compriseprogramming has long been a major problem for industry (Pea &

Kurland, 1983b), and is becoming so for schools. We define program-ming as the set of activities involved in developing a reusable productconsisting of a' series of written instructions that make a computeraccomplish some task. But in order to move from definition to in-struction, one must begin to unpack "programming skill," in contrastto the black-box approach to programming prevalent in schools.Promising moves in this direction have already been provided bycareful analyses of what expert programmers do, and what types andorganizations of knowledge they must draw on when they program.This research strategy, characteristic of cognitive science, has re-vealed significant general features of expert problem-solving skills fordiverse domains, such as algebra (Lewis, 1981), chess (Chase &

Simon, 1973), geometry (Anderson, Greeno, Kline & Neves, 1981),physics (Chi, Feltovich & Glaser, 1981;. Larkin, McDermott, Simon &

Simon, 1980), physical reasoning (deKleer & Brown, 1981), andwriting (Bereiter & Scardamalia, 1982), and it is providing newinsights into the components of programming skill.

What does a programmer do? Programming, for either novices orexperts, involves a set of activities which constitutes phases of theproblemrsrlring process (e.g., Newell & Simon, 1972; POlya, 1957).TheSef act 'Meg, which may be invoked at any time and recursivelyduring the development' of a .program, are: (1) understanding theprogramMing problem; (2) designing or planning a programmingsolution; ,(3) writing the' programming 'cede that implements the plan;and ,.(4) compreheneion of the written program and program debug-ging:. An extensive review of these cognitive subtasks of program-Ming may be found in Pea and Kurland (1983b).

Whit. must an expert programmer know? Findings on the knowledge.schemas, :memory organizations, and debugging strategies whichexpert 'programmers possess are of particular interest. RecentstUdies of Programmers' characterize high-level programming skill as agiant astemblage of highly .specific, low-level knowledge fragments.(Atwood & Ramsey, 1978; 'Brooks, 1977). .The deSign of functional"programmer'S apprentices" such as Barstow's (1979) Knoviledge BasedProgram: Construction,. and Rich and Shrobe's "Lisp programmer'sapprentice" (Rich & Shrobe, 1978; Shrobe, Waters & Sussman, 1979;WaterS, 1982), and the 'MEND Programming Tutor (Soloway, Rubin,WoOlf; Bonar & Johnson, 1982) has involved compiling.a "plan library"of the basic programming schemas, or recurrent fUnctiOnal chunks ofprogramiting,, code that programmers, are alleged to use. 'Observationsof programmers support these introspective analyses of chunks ofprOgramming knowledge. Eisenstadt, 'Laubsch and Kahney .0981)found that most novice, student Programs were constructed from asmall sit of program.schematt, and when Jeffries (1982) compared 'thedebugging strategies of ,novice .prograMmers and graduate computerscience studentS,, she found that experts .saw whale blocks .of. code asinstantiations of well -known problems such as calculating change.Soloway and colleagues (Sonar, 1982; Ehrlich & Soloway, 1983; John-son, Draper & Soloway, 1983; Soloway & Ehrlich, 1982; Soloway,Ehrlich, Bonar & Greenspan, 1982; also see Kahney & Eisenstadt,1982) postulate a model in which programmers use recurrent plans aschunks in program composition, and identified such plans it programswritten by Pascal novices (e.g., the "counter variable plan"). Butfor developmental cognitive science, we will need studies Of howstudents mentally construct such plan schemas from- programminginstruction, experience, and prior knowledge.

A related aspect of programming skill is the set of rules that expertsuse to solve programming problems, but again wif. lack geneticstudies. In an analysis of a programmer's think-aloud work on 23different problems, Brooks (1977) demonstrated that approximately 104rules were necessary to generate the protocol behavior. Similarly,Green and Barstow (1978) note that over a hundred rules for mechan-

15

18

ically generating .simple sorting and searching algorithms (e.g. ,Quicksort) are familiar' to most programmers.

A third aspect of programming skill is the 'ability .to build detailedmental models of what the computer will do when a program runs. Anexpert programmer can build dynamic mental representations, or"runnable mental models" (Collins & Gentner, 1981) and simulatecomputer operationg in response to specific problem inputs. Thecomplexities of such dynamic mental model's are revealed vhen skilledprogrammers gather evidence for program bugs and simulate theprogratt's actions by hand (Jeffries;, 1982). Not all program under-standing' is mediated by hand. siniulation; experts engage in 'globalsearches for program. organizational structure, guided by adequateprogram documentation, a strategy akin to *bat expert readers do(Brown,, ,1983b; Brown & Smiley, 1978; spito, Bruce & Brewer, 1980).,How individuals develop such rich procedtiral understanding is curH:rently unknown.

Expert programmers not only have available, more knowledge ,schemas iistrategies, and rules applicable to 'solving, programming problems,. butthey perceive and remember larger chUnks, of information than ,donovices. . The classic Chase .and. Simon.' (1973) finding, of short7termtitatory span 'advantagei for chess experts over'noVicesE for meaningiful chessboard 'configurations but not for ,random 'Configurations has

:replicated for programming (cultist.. shepo4rd Borst &LoVe 1979; McKeithen,' Reitman, Rueter '& , Hirtle., 1981;. IstOrcioKerst, in press; ShepPaid, CUrtis,, 1979; Shneider-man , '1977) . For example, MCISeitlieri expertsclustered keyword commands- according to meaning (e.g.., those func-tioning in loop statements), 'whereas novices Clustered according to avariety of surface ordinary language associations (such as ortho-graphit similarity and ..wOrd length), intermediates falling between thetwo. Similarly, Adelson (1981) found 'that recall clusters for expertswere functionally or deeply based;. those of novices Were based onsurface. features of programming code. This is a Major developmentaltransformation, but we do not understand how it occurs. DiPersio,Isbister and Shneiderman (1980) extended this research by demon-strating that performance by college students on a program memoriza-tion /reconstruction task provides a useful predictor of programmingtest performances.

ti

It is also a widely replicated finding that expert programmers debugprograms in different ways than do novices (Atwood & Ramsey, 1978;Gould, ,1975; Gould & Drongowski, 1974; Youngs, 1974). Jeffries(1982) found that program debugging involves comprehension proc-esses analogous to those for reading ordinary language prose. Ex-perts read programs for flow of control (execution), rather than

vA

line by line (as text), But how do programmers shift from surface todeep readings of programs as they develop debugging skills?

In conclusion, we make one important observation, Expert program-me :s know much more than the facts of programming language seman-tics and syntax.. However, the rich knowledge schemas, strategies,rules, and memory organizations that expert programmers reveal areonly rarely directly taught. Many programming students are at adisadvantage because of their lack of such. understanding. This doesnot mean that they could not be taught, but to do so effectively willrequire considerable rethinking of the traditional computer sciencecurriculum. These cognitive qualities appear instead to be a conse-quence of /an active constructive process of capturing the lessons ofprogram writing experience for later use.

Levels of Programming Skill Development

To date,. observations of levels of programming skill development (seeHowe, 1980) have been extremely general and more rationally thanempirically derived. Accounts of novice- expert differences in pro-gramming ability among adults, coupled with observations of childrenlearning to program, provide a starting point for developing a taxon-omy, of levels of programming proficiency. This taxonomy can guideour research by providing a developluental framework within which toassess a students' programming expertise and make predictions fortypes of transfer beyond programming, as a function of a student'slevel of expertise.

We believe that at least four distinct levels of programming ability canbe identified that have implications for what types of skills mighttransfer as 'the' result of their achievement. 'These levels representpure types si-and may not be characteristic of an individual, but cap-ture some Of the complexities of what it means to develop programmingskills. We view these levels only as guidei toward more adequatecharacterizations of the develoPment of programming abilities. Fur-ther differentiation will inevitably be required, in terms of the cog-nitive subtasks involved in the levels, and refined sublevels.

Level Is Program user. A student typically learns to execute alreadywritten programs such as games, demonstrations, or computer-assistedinstruction lessons before beginning instruction in how to program.What is learned here is important (i.e., what specific keys do, how toboot a disk, how to use screen menus), but does not reveal how theprogram works. or that the program controls what happens on thescreen. For many people, this level is sufficient for effective com-puter use (e.g., for word processing, game playing, electronic mail).But in order to be more in control of the computer and able to tailor

17

.!rJh'?

its capabilities to one's own goals, some type of programming isrequired.

From this level we would expect relatively little transfer beyondcomputer use, but some transfer on computer literacy Issues. Forexample, given sufficiently wide exposure to different types of pro-grams., ,a student would be expected to know what computers arecapable of doing, what they cannot do, and fundamental aspects ofhow they function in their everyday lives. As users, then, childrenmight learn when computers are appropriate tools to apply to a prob-lem..

Level II: Code generator. At thii level the student knows the syntaxand semantics of the more common commands in a language. He orshe .can read someone' else's program and expl&n what each lineaccomplishes. The student can locate bugs that prevent commendsfrom being executed (e.g., syntax errors), can load and save pro-gram, files to and from an external 'storage deyice, and can writesimple programs of the type he for she has seen previously. Whenprogramming, the student does very. little preplanning and- does notbother to document his or her programs. There is no effort tooptimise the coding,, use error traps, or make the program usable byothers. A program created at this level might just, print the stu-dent!s. name repeatedly on the screen or draw the :Same shape againand again in different colorS. The student operates at the level ofthe individual ,command and, does. not use subroutines or procedurescreated as part- of other programs. This level of understanding ofthe ../programming process is z sufficient for creating short programs.But 'to create more useful and flexible programs, the student needs toprogress at.least to the next level.

At level II, more specific types of computer literacy related transferwould be expected. Students should develop better skills for dealingwith the more sophisticated software tools that are rapidly permeatingthe business world. Computer-naive users of office informationsystems (including calculators) have many problems (e.g., Mann,1975; Nickerson, 1981b) and construct naive, error-ridden mentalmodels of how they work (Mayer & Bayman, 1981; Newman & Sproull,1979; Young, 1981). Knowledge characteristic of this level may berequired to attenuate these problems. Sheil (1980, 1981a,b) providescompelling arguments that most systems require low-level programmingif the user wishes to take advantage of system options, a basiccompetency he has designated as "procedural literacy."

While potential computer literacy transfer from low-level programmingexposure seems a reasonable expectation, what types of cognitivetransfer should occur from this level of programming expertise is

18 21

disputable. Our observations of children programming at th:s levelsuggest .that Some appreciation of the distinction between bugs anderrors, degrees of correctness, and the value of decomposing programgoals .into manageable subparts may develop and transfer to otherdomains., -tut that a student's attention is typically so riveted toSimplY getting a .program to work that any appreciation for moregeneral cognitive strategies is lost.

Level, Program Generator. At this level, . the. student has mas-tered the. basic commands ,and is beginning to think in, terms ofhigher level...units. He or she knows that sequences, of commandsaccomplish Program , goals (e.g., locate and verify a keyboard input,sort a list of names or numbers, or read data into' a program from aseparate text file). The student can read. a program and explain itspurpose, what functions different parts of the program Serve, andhow the different parts are linked together. The student can, locatebugs that cause the program to misfunction (e.g., a sort routine thatfails to correctly place the last item in a list) or bugs that cause theprogram to crash as a' result of unanticipated conditions or inputs(e.g., a division-by-zero error .ihen the , program is instructed tofind' the Mean of a null list). . The student can lOad, save, and, merge,files and do simple calls to and from files inside the main program.The student 'may be,-writing fairly lengthy..programs for personal use,but the programs tend not to be user - friendly. While the studentsees the need for documentation, -he or .she dOes not plan programsaround the need for 'careful documentation or clear coding so that theprogram may be maintained by others. For this. general level, onecan expect to identify many sublevels, of programming. skill.

Within this level of expertise, students shOuld develop some appreci-ation for the process of &Signing a successful program. Such un-derstanding has potentially powerful implications for their work inother domains, particularly if such relationships are explicitly drawnby the teacher for students, or exemplified in other domains. How-ever, it _appears from our classroom observations and interviews. withteachers that for students to spontaneously, transfer computationalconcepts or language constructs used in one area of programming toother programming projects is a major accomplishment. Ideas aboutwhen to use variables or the value of planning, as in designingprogram ,,omponents so that they can be reused in the future, andfollowing systematic conventions (such as beginning all graphicsdesigns at their lower left corner) to make merging components intoprograms easier are all important accomplishments at this level thatshould not be taken for granted.

Level IV: Software developer. Finally, at this level the student isready to write programs that are not only complex and take full

19

22

advantage of the capabilities of the computer, bUt are intended to beused by others. The student now has 'a full understanding of all thefeatures of a language and how the language interacts with the hostcomputer (e.g., how memory is allocated or how graphic buffers maybe protected from being overwritten). When given programs to read,the student can scan the. code and simulate mentally what the programis doing., see how the goals are achieved and how the .programs couldbe better written or adapted for other purposes. Programs are nowwritten with sophisticated error traps and built-in tests to aid in thedebugging process and to ensure that the "program is crash-proof.Beyond .writing code accomplishing the program's objective, the stu-dent can optimize coding to increase speed and minimize the memoryrequired to run a program. To decrease the time needed to writeprograms, he or she draws heavily on software libraries and prOgram-ming utilities. Finally, he or she often crafts a design for the. pro-gram, before generating the code, documents ., the program fully, andwrites the program in a structured, modular. fashion so that otherscan easily read and modify it. Major issues in software engineeringat high sublevels. within this level of expertise are discussed byThayer, Pyster and Wood (1981) .

It is at this level of programming sophistication that we would expectto see the most extensive evidence 'for cognitive transfer. Thestudent can distance him/herself sufficiently from the low-level codingaspects of program generation to reflect on the phases and processes...,of problem solving involved. The issues of, that concernthe student at this levelelegance, optimalization, efficiency, veri-fication, provability, and stylebegin to transcend low level concernswith program eitecution, and may lead him or her to consider widerissues. The need 'at this level to be conscious of the range of in-tended users of programs forces the student to take the audiencefully into account, a .skill that has wide applicability in many otherdomains, such as writing.

Implicit in these distinctions between levels of programmir g skill andtheir link to predictions about types of transfer is a theory of pro-gramming at odds with the naive technoromanticism prevalent ineducational computing. While it is conceivable that even low levels ofprogramming skill are sufficient to produce measurable cognitivetransfer to nonprogramming domains, we contend that on the limitedevidence available, this would be unlikely. Students who can barelydecode or comprk.hend text are not expected to be proficient writers.Similarly, we doubt that students with a low-level understanding ofprogramming and the skills that programming entails will write func-tional programs or gain insights into other domains on the basis oftheir limited programming skill.

20 23

Cognitive Constraints on Learning to Program

Beyond asking what general cognitive characteristics may be prere-quisite to or substantively influence a child's learning to program,some ask what "developmental level" children must be "at" in order tolearn from programming experiences. The concept of developmentallevel at the abstract theoretical planes of preoperational, concreteoperational, and formal operational intellectual functioning has provedto be useful for instructional psychology in understanding children'sability to benefit from certain types of learning experiences (e.g.,Inhelder, .Sinclair & Bovet, 1974). But the very generality of thesestage- descriptions is not suitably applied to the development of spe-cific domains of knowledge such as programming skills.

We have two reasons for not pursuing the development of program-ming skills in terms of Piagetian developmental levels. First, there isstrong evidence that the development and display of the logical abili-ties defined by Piaget is importantly linked to content domain (Feld-man, 1980; Gardner, 1983; Piaget, 1972), to the eliciting context(Laboratory of Comparative Human Cognition, 1983), and to the,particular experiences of individuals (Price-Williams, Gordon 'ilkRamirez, 1969). Since it is not apparent why and how differentmaterials affect the developmental level of children's performanceswithin Piagetian experimental tasks, it is not feasible to predict therelationship between learning to program and performance on thePiagetian tasks. Our second objection is that learning to program hasneither been subjected to developmental analysis nor characterized interms of its 'component skills, although such analyses are necessaryfor articulating measures that indicate the availability and develop-mental status of these skills for particular learners.

While no research has been directly aimed at defining the cognitiveprerequisites for learning .to,lprogram, at least six factors are fre-quently mentioned: mathematiCal ability, memory capacity, analogicalreasoning skills, conditiOnal reasoning skills, procedural thinkingskills, and temporal reasoning skills. These cognitive abilities, eachof which has a complex f and well-researched developmental history,are presumed to infliience learning to program and could be promisingdirections for future research.

Mathematical -Beyond general intelligence, programming skillis said to be linked to general mathematical ability. Computers werefirst developed to help solve difficult mathematical problems. Al-though many computer uses today are nonmathematical (e.g., databasemanagement, word processing), the notion persists that in order toprogram one must be mathematically sophisticated. Media accounts ofchildren using computers in schools have perpetuated the belief that

21

24

programming is the province of math whizzes. Although we doubtthat math and programming abilities are related once general intel-ligence is factored out, math ability cannot be ruled out as a pre-requisite to the mastery of certain levels of programming skill.

Processing. capacity. Programming is Uten a memory-intensive enter-prise requiring great concentration and the ability simultaneously tojuggle the values of a number of parameters. Thus, individualdifferences in processing capacity are a likely candidate for in-fluencing who becomes a good programmer. Forward and backwardspan tasks, and more recently developed transformational span meas-ures (see Case & Kurland 1980; Case, Kurland & Goldberg, 1982),assess how much information one can coordinate at a given momentand appear to index processes basic to learning. Performance onsuch tasks has reliably correlated with general intelligence, 'Piagetiandevelopmental level, and ability to learn and use problem-solvingstrategies (e.g., Hunt, 1978).

Analogical reasoning. A student may have background knowledge andcapacities relevant to programming, yet neither connect them to theprogramming domain nor transfer knowledge acquired in programmingto other domains. This access of knowledge is fundamental to learn-ing and problem solving throughout life (e.g., Brown, 1982). Trans-fers of knowledge and strategies, both "into" and "out of" learning toprogram, may depend on analogical thinking skills. Tasks designedto measure abilities for engaging in analogical thinking (e.g., Gick &

Holyoak, 1980; Sternberg & Rifkin, 1979) may predict level of pro-gramming development and transfer outcomes. Mayer (1975, 1981)argues that students learn programming by comparing the flow ofcontrol intrinsic to computational devices to the physico-mechanicalmodels that they already possess. Also, duBoulay and O'Shea (1976,1978) have successfully used extensive analogical modelling to explaincomputer functioning to novice 12-year-old programming students.

Conditional reasoning. Working with conditional statements is a majorpart of programming, since they guide the operation of loops, tests,input checking, and other programming functions. Thus, it is rea-sonable to predict that a student who has sufficient understanding ofconditional logic--the various "if...then" control structures and thepredicate logical connectives of negation, conjunction, and disjunc-tion- -will be a more successful programmer than a student who hastrouble monitoring the flow of control through conditional statements.

Procedural thinking. Several kinds of quasi-procedural, everydaythought may influence how easily a learner masters the flow of controlprocedural metaphor central to understanding programming, includinggiving and following complex instructions (as in building a model),

22

25

writing or following recipes, and 4oncocting or carrying out directionsfor travel. Presumably, learners more familiar with these linearprocedures, analogous to the flow of control for computer operationsexpressed as instructions in a computer program, will more readilycome to grips with the "procedural thinking" touted as a central facetof programming expertise (Papert, 1980; Sheil, 1980). However, todate there has been little study of the development of proceduralthinking.

Temporal reasoning. The activity of temporal reasoning is relited toprocedural thinking, but with a distinct emphasis. Creating andcomprehending programs requires an understanding of the temporallogic of sequential instructions: "it is the intellectual heart oflearning how to program" (Galanter, 1983, p. 150). In teachingprogramming, Galanter says:

The central theoretical concept that guided this effort wasthat classical forms of spatial-geometric-pictorial thinkingmust be augmented, and occasionally replaced, by temporal-imaginative-memorial logic. The, child must learn to substi-tute an inner temporal eye for the outer spatial eye.(p. 163).

Going somewhere in the program next, running one subroutine orprocedure before another, ensuring one counter does not exceed acertain value until' another operation is performed--these fundamentaloperations all require temporal understanding. Yet understandingtemporal terms is a major, developmental achievement, a challenge forchildren younger than seven or eight (e.g., Friedman,, 1982; Piaget,1969). Futurity also presents complex conceptual problems for theplanning activities involved in programming, such as imagining out-comes of the possible worlds generated by program design options(Atwood, Jeffries & Poison, 1980), or the "symbolic executions" whilewriting programming code (Brooks, 1977).

In sum, the cognitive constraints on developing programming skillsare currently unknown. Although a developmental cognitive scienceperspective predicts that a student's attainable level of programmingskill may be constrained by the cognitive abilities required in pro-gramming, there are no studies that relate level of programming skillto the abilities we have described. Children may have conceptual andrepresentational difficulties in constructing dynamic mental models ofongoing events when the computer is executing program lines thatconstrain their level of programming skill. Also, systematic butnaive mental models or intuitive epistemologies of computer proceduralfunctioning may initially mislead children's understanding of program-ming, as with adult novices. Since learning to program is difficult

2623

for many students, there is a serious need for research findings thatwill guide decisions about tailoring programming instruction accordingto a student's relevant knowledge prior to learning to program.

Exicmsefo2_2-Co Pro rannin

We now return to the claims for the broad cognitive impact of pro-gramming experience with greater awareness of the complexities oflearning to program and issues of transfer. In sum, there is meagerevidence for these claims.

Dramatic accounts have been offered of how some school-aged chil-dren's thinking about their own abilities to solve problems is trans-formed through learning to program (e.g., Papert et al., 1979; Watt,1982; Weir, 1981; Weir & Watt, 1981). Important social interactionalchanges have been demonstrated in classrooms where children arelearning Logo programming (Hawkins, Sheingold, Gearhart & Berger,1983) and, for some children, programming is an important and deeplypersonal intellectual activity. Similarly, many teacher reports focuson social and motivational rather than cognitive aspects of this expe-rience (Sheingold, Kane, Endreweit & Billings, 1981; Watt, 1982). Itis not yet clear what the cognitive benefits of programming for suchchildren may, be in terms of the transfer claims reviewed earlier.

On the cognitive side, Ross and Howe (1981) have reviewed ten yearsof relevant research to evaluate Feurzeig et al's (1969) tour generalclaims on the cognitive impact of programming. The relevant researchhas been with Logo in nonrepresentative private schools. Below, wesummarize Ross and Howe's review and integrate summaries of otherstudies relevant to these claims. In terms of our account of levels ofprogramming skill and the expected transfer outcomes, we mustcaution that, so far, studies (including our own) have an importantlimitation. 'They have all looked at what we have designated ashigh-level or cognitive-transfer outcomes, expected to emerge only atthe higher levels in .our account of programming skill, whereas thelevels of programming attained by the students in these studies werelow because they only did six weeks to a year or so of programming.In other words, there has been a mismatch of "treatment" and trans-fer assessments because of a failure to appreciate the different kindsof transfer to investigate and their likely linkage to different levelsof programming skill. For example, there are no studies that haveassessed the low-level transfer or application of programming conceptssuch as "variable" in different types of programming within a lan-guage (e.g., graphics versus list processing in Logo), or from oneprogramming language to another, or of computr literacy outcomes.

24 27

First, were are no substantial studies to support the claim thatprogramming promotes mathematical rigor. In a widely cited study byHowe, O'Shea and Plane (1979), researchers who were highly trainedprogramMers spent two years teaching Logo programming to eleven11-year-old boys of average or below average math ability. Theystudied Logo the first year and math with Logo the second year, eachboy working for one hour per week in a programming classroom.When Logo students were compared with nonprogrammers (who onpretest had significantly better scores on the Basic Mathematics Test,but equivalent scores on the Math Attainment Test), they had improv-ed enough in basic math to eliminate the original performance gapwith the control group, but fen significantly behind on the MathAttainment Test. Such global math score differences do not supportthe rigor claim. The oft -cited finding is that the. Logo group learnedto argue sensibly about mathematical issues and explain mathematicaldifficulties clearly, but the finding is based only on differences inratings of Logo and control students in teacher queitionnaires (Howeet al., 1979). The reliability of such ratings is questionable, sincethe math teachers should have been blind to which students learnedLogo.

Second, there are no reports. dethonstrating that programming aidschildren's mathematical exploration. Rem' by Dwyer (1975) forchildren learning BASIC, and Howe et al., Lawler (1980), andPapert . et al. ( 1979).. for, those using. Logo, :go document children's,oal- directed exploration of mathematical concepts such as variable oncomputers. Although math exploration and "mathland" play are likelyto support math learning studies have notnote shown any effects ofmath exploration during programming outside the programming envi-ronment.

Third, although Feurzeig at al. (1969) suggest that the twelve 7- to9-year-old children to whom they taught Logo came to "acquire ameaningful understanding of concepts like variable, function andgeneral procedure," they provide no evidence for the claim thatprogramming helped the children to gain insight into these mathemat-ical concepts.

Finally, we ask whether programming has been shown to provide acontext and language that promotes problem solving beyond program-ming. Papert et al. (1979) conducted a Logo project with sixthgraders for six weeks and reported, through anecdotal material, thatchildren engage in extensive problem-solving and planning activitiesin learning programming. Whether or not such activities had cogni-tive effects beyond programming was not studied. However, Statz(1973) carried out a study to assess this claim. Logo programmingwas taught to sixteen 9- to 11-year-old children for a year. Statz

25

chose four problem-solving tasks with intuitive, ill-specified con-nections to programming activities as transfer outcome measures. Theexperimental group did better on two of these tasks (word puzzle anda permutation task), but no better on the Tower of Hanoi task or ahorserace problem that Statz jtad designed. She interprets thesefindings as mixed support for the claim that learning Logo program-ming promotes the development of more general problem solving skills.

Soloway, Lochhead and Clement (1982), in reaction to the finding thatmany college science students have difficUlty translating simple algebra word problems into equations (Clement, Lochhead & Monk, 1979)found that more students solve such problems correctly when they areexpressed as computer programs rather , than as algebraic equations.They attribute this advantage to the procedural semantics of equa-tions in programs that many students lack in the algebraic task.This effect is much more restricted in scope than the increments ingeneral problem solving skill predicted by the cognitive transferclairds.

An important idea is that not only computer programs but one's ownmental activities can lead to "buggy" performan,ces and misunder-standings. Tools for diagnosing different types of bugs in suchprocedural skills as place-value arithmetic (Brown 6 Burton', 1978;Brown l VanLehn, 1980; VanLehn, 1981) have resulted from extensiveprogramming efforts to build "bug diagnostic systems" (Burton,1981). One may argue that the widespread recognition that systematic bugs may beset performances in other procedural skills, such ashigh schoOl algebra 1Carry, Lewis I Bernard, 1979; Matz, 1981)reflects a kind of transfer beyond programming. There is no evi-dence that programming students demonstrate such transfer.

Planning in advance of problem solving, and evaluating and checkingprogress in terms of goals, are important aspects of a reflectiveattitude to one's own mental activities (Pea, 1982). We have seenthat the development of planning abilities, is one major predicted

Wcognitive benefit of learning to program. We therefore developed atransfer task for assessing children's planning (Pea & Hawkins,1983). We reasoued that a microgenetic method (Flavell & Draguns,195 ?) allowing children to develop multiple plans was comparable tothe rounds of revisions carried out during programming, and wouldallow for a detailed study of planning processes. Children plannedaloud while formulating, over several attempts, their shortest-distanceplan for doing a set of familiar classroom chores, using a pointer toindicate their routes. We gave the task twice, early and late in theschool year, to eight children in each of two Logo classrooms (8- and9-year-olds; 11- and 12-year-olds), and to a control group of thesame number of same-age children in the same school. There were

2926

six microcomputers in each classroom, allowing substantial involvementwith programming.

As. in related ..work. on adult's 'plr.nning processes by Goldin andHayes-Roth .(19801 also .HaYes-Tt..th, 1980; Hayes-Roth & Hayes-Roth,.1979)4 our product analyseS' centered on' "plan goodness" in terms ofMetrics of route_efficiency, and our ..process analyses centered on thetypes and sequencing of -.planning 'decisions. made. (e.g., higher levelexecutive and metaplanning decisions such as what strategic. approachto take to the 'probleni,' versus loiter level decisions of what route totake..between ,. two chore.act's). Results 'indicated that the Logo :pro-graMMing experiences had no significant effects. on planning perform-ances, On any' of the plan ffidency. or planning process measures.(Pea & Kurland., ..1983a). Replications of this work are currentlyunder way with children in other schools.

Conclusions

As our society comes to grips with the information revolution, theability to deal effectively with computers becnmes an increasinglyimportant skill. How well our children learn to use computers todaywill significantly affect the society of tomorrow. The competentappliCation .of higher cognitive skills such as Planning and problem-solving. heuristics in mental' activities, both with and without .com-puters, is 'a critical aim for education. As one contribution to theseissues, we .have argued for and documented throughout this paper theneed for a new approach to addressing questions about the cognitiveeffects of computer , programming. This approach, which we havecharacterized as developmental cognitive science, does not adopt thecommon perspective that computer programmers are all like adults,but is geared instead to the learning experiences and developmentaltransformations, of the child or novice. The proposed research wouldbe attentive to the playing out of those processes of learning anddevelopment in the instructional and programming environments inwhich the novice gains expertise.

Can children become effective programmers? Does learning to pro-gram positively influence children's abilities to plan effectively, thinkprocedurally, or view their flawed problem solutions as "fixable"rather than "wrong"? We have shown that answers to these questionsdepend on how "learning to program" is defined. We have reviewedcognitive science studies revealing that programming involves a com-plex set of skills, and have argued that the development of differentlevels of programming skill will be highly sensitive to contexts forlearning, including processes of instruction, programming environ-ment, and the background knowledge the student brings to the task.We found few studies that could inform this new understanding,

27

30

although many promising research questions have been defined fromthis perspective.

We have disinissed 'two prevailing myths about learning to program.The myth eMbodied in most 'programming instruction--that learning toprogram is "learning iacts" of programming language semantics andsyntaxis untenable for two reasons: (1) it leads:--to major con-cePtual misunderstandingd, even among. adult programmers; and.(2) what is taught belies what cognitive studies show ;good pro-graminers *dO' and know. These studies have direct implications fornew content and methods for programming instruction that are underdeVelopmenti in Several, cfuarterS. Studies of, learning to program andof transfer outcomes are riot yet Available for cases where instructionhas such nontraditional emphases (e.g., on task analysis and prob-lem-solving methods that take advantage of what we know expert'programmers do). ,We have also argued againit the second myth --thespontanem., 'transfer of higher cognitive skills, from learning to pro-gram to Other domains. Resistance in learning to spontaneous trans-fer and the :predicted linkages of kinds, of transfer beyond program-Ming to the learner's level of programming skill were major points ofthese critical reviews.

When thinking .about ,children learning to program, what skill, levelscan be expected? Reports of children learning to program (Howe,1981: Levin & .Karise, 1980; 'Papert et al., 1979; Pea et al., 1983),including the learning disabled, the cerebral palsied, and the autistic(Watt .& Weir, 1981; 'Weir, 1981) , suggest that Most children can learnto write ,correct lines of code (level II in our account). This is nosmall achievement since writing grammatically correct lines of code isall that many college students achieve in their first programmingcourses (Boner & SOloway, 1982) . This level of programming skillmay depend on the same abilities necessary for learning a first lan-guage.

However, for programming skills that are an aid in problem solving,"grammatical" programming alone is inadequate; the student mustknow how to organize code and plan schemas in order to accomplishspecific goals. Development to these higher levels, where one be-comes facile with the pragmatics of programming, may require stra-tegic and planful approaches to problem solving that are traditionallyconsidered metacognitive, and more characteristic of adolescents(Brown et al., 1983) than primary school children. Further, theexperience of the child in an elementary or junior high school pro-gram who spends from 30 to 50 hours per year in programming isminuscule when compared with the 5,000 hours which Brooks (1980)estimates a programmer with only three years of experience has spenton programming. Since it is unreasonable to expect children to

28 31

.10

become advanced programmers in the few years available to them inmost school programming courses, our educational goals should bemore realistic and achievable. As yet, we do not know what levels ofprogramming expertise to expect but, in our experience, children whoare programming experts are uncommon. Thus, there are large gapsbetween what is meant by learning to program in the computer science

, .

literature, and what learning programming means to educators inter-ested in introducing children to this domain. These discrepanciesshould temper expectations for the spontaneous effects on children'sthinking ,Modes of .their limited programming experiences in school, atle* for how programming is taught (or not taught) today. Whetherresearch on learning iii:program with richer learning experiences and

will lead to powerful outcomes remains' to be seen. Inplace 'OE"i naive technoromanticism, we have predicted that the levelof programming abilities a student masters will be a predictor of thekinds of .concepts and skills* he or she will transfer beyond program-ming. ,'Although findings to date of transfer from learning to programhave not been ,encouraging, these studies err in not 'linking level ofprogramming skill . to expected outcomes, and the critical studies of

transfer expected from levels and II remain to be carriedout. More importantly, with thinking skills as educational goals, itmay be beeet to provide direct guidance that teaches or models trans-fer as a general aspect of highly developed thinking processes (Chip-man., Siegel & Glaser, 1983; Smith & Bruce,,, 1981), Programming mayprovide an excellent domain for Such purposes (Nickerson, 1982;Papert, 1980.

Throughout this paper, we have emphasiZed the need for developmen-tal reeearch, in this area: empirical studies to refine our character-

,

izations of levels, of programming proficiency; extensive evaluations ofthe extent of transfer within and' beyond programming in terms ofdifferent programming and instructional environments; and studies tohelp untangle the complex equation, involving cognitive constraints,programming experience, and programming outcomes. We believe allthese, questions could be addressed by longitudinal studies of thelearning and development process by which ludividual students becomeproficient (or not-so-proficient) programM&S, and of the cognitiveconsequences of different levels of programming skill. Such studieswould provide more relevant information for guiding the processes ofeducation than standard correlational studies. A focus on processand the types of interactions that students with different levels ofskills have with programming and instructional environments is criticalfor understanding how development in programming skill 'is related toother knowledge. We are optimistic that others will join in work onthese questions, for progress must be made toward meeting theeducational needs of a new society increasingly empowered. by infor-mation technologies.

32 29

4'

Footnotes

f

1The expectation "that learning the concepts and language thatunderlie Programming will ch ange the way-a learner thinks of nonpro-gramreing problems recalls the strong formulation of the Sapir-Whorfhypothesis--that available linguistic labels constrain availablethoughts. The strong form of this hypothesis has been extensivelyrefuted (e.g., Cromer, 1974); only a weak version is consistent withevidence on lariguage-thought relationships. Available labels in one'slanguage may facilitate, but are neither. necessary nor sufficient for,particular forms of thinking or conceptual distinctions. Categories ofthought may provide the foundation for linguistic categories, not onlythe reverse. The same point applies to the language of programming.

2In (artificial) programming languages, just at in natural lan-guages, one may ,distinguish among three major divisions of semiotics,or the scientific study of properties' of such signalling systems(Crystal, 1980). These three divisions, rooted in the philosophicalstudies of Peirce, Carnap, and Morris, ares

Semantics,. the study of the relations between linguistiC.expressions and the .objects in the world -which they, ,!referto or describel, ,syntactice, the study,, of. the relation ofthese .expressions to each other; and prim the studyof the dependenCe of ..the meaning of these expressions ontheir users (including the social situation in which they areused). (op. p. 316)

Studies of natural language pragmatics have focused on toe

study of the language from thi point of view of the user,especially of the choices he makes, the constraints heencounters in using language in social interaction, and theeffects his use of language has on the other participants inan act of communication. (op. cit., p. 278)

Though there are important disanalogies to natural language, a prag-matics of programming languages concerns at least the study ofprogramming language (s) from the point of view of the user, espe-cially of the (design) choices he or she makes in he organization oflines of programming code within programs (or software systems); theconstraints he or she encounters (such as the requirements of adebuggable program that is well-documented for future comprehensionand modification) in using programming language in social contexts;and the effects his or her use of the programming langupge has onthe other participants (such as the computer, as ideal interpreter, or

. ..

. -.,-Othei humane).- 'in an act" of communication involing the use of the. k k I. , ., ,

... programming language:- ,.,

OperatiOns. that a, need-,..cOMputer. program.' specifies. The. tnee '-for....the.terM-..,,..!4-..

T:he concept of -:,11.001N..:.:,:of _. control" refers to the- sequence 'of.

: , einerges;-.,-beeai0e.:. ipt-... all:contra:J:3- linear. ...:,..-In -linear' control, -lines of "., . :-.,,.....,,,,::..programming instructions would be executed In Strict !:,Iinear: order--first,

. ..:......".,:.:0

..:,. :.iecand, '''..thii4,.: lind.. -0O. .on:'. But in .viitooly au.,piogramaling. .:..r. 1 ' -0 ; , . . , , ,,, ' '.L . , ' . ; .: '- ....! ii '..'.

. Y ' ' '4' ; : ..i.

languages, 'H,ya,4014.8 !T.!,',Control.,:structures";.-are,..-Used, `..to. .allow :nonlinear '._-"-,:,-:-J'-';\control. For example, one may ".CiOTO"' other than the. next -line .in'... . ,

the program :01,13A-Sic ,-.'.ln:-NiihiCli case flow of ,..cOrittOl,:passeti'to--- the :`-7,,,-.:.77.7!.

line':of.prOgramMing,code:: referijd.. to In the,:..-GOTC).:'-,'Statiitient. ..Be-,'..otige:.11prOgram,S-:-floW of ,control May-'becomplex;-.programmers.:Often. .. . t"'.'6:-':',,

. utilize ."-prOgramMing flowcharts, either to serve as :, a high-level ....Olin,.for "creating' ,,,their,- program, or to document the how of control In

,,, ... ..:

.., . l.,

their .prograin.. .. . .. : . 7 .. -. . - : , ; :: ,,, '.:: .' : .,

6

4 . ...,

What Is "quasi-procedural" rather than . "procedural" . aboutgiving and following task instructions, diectlofls, and -: reCipes.:: is .'' 4 t,..y.:';r,

often ambiguity in the everyday ekampleis, _SuCh:-,that,the -inStructions,,that, unlike procedural instructions in a computer 'Program. there is

: are 'also not constrained , by strict ,:seituentiolity. ..,;Pne,:maY.:..often ...choose- to bypass steps in a' recipe. ,Or Set of:instruCtione,. or to , ,>

reorder the steps. : Neither. option is, available.inli the Str,ict procedur=.'

directions, 'and recipes are not alWayS. unequivocal in meaning. They .: ''' '

.,:' '' ;..,.,;

, .

,

ality of programmed Instructions. Yet Omilarities.'.between ;theeVery-,day cases and programming instructions are ,compelling enough: tomake their designation as quad-procedural Understandable:

1 I

3431

,o 21,

-t.i}1&!t

l')

-

.,

References

Abelson, H., b DiSessa, A. Turtle eoic 1...Atli.. Cambridge, MA: MITPress, '1981.

Adelson, B.. Problem solving and the development of ,abstract cate-gories in programming 'languages. Memory and Cognition, 1981,9, 422-433,

Anderson; J. Greeno, t. .4,, Kline, Pi J., & .Neves; D. M.I'

. A qUiti#1611. o f soling skill. In' .1. AndeisanCognitl'e skills and ,eir sic 'Weldon. Hillsdale; NJ:

1

A 44e R. E. National computer literacy, 1980; ;:In. R. 3. Seidel,R. E. Anderson, Hunter, , (Eds. ), Computer literati: Issuesand directioe for 1985.,

NOW Torki: .Academic PresS, 1982.14

Atwood, ieffriesi R., t-Polson, IS C. Studies 'in plan con- ,0

struction., Is Analysis an --extended Ovtaccil (Tech. Rep. No.SA11-80.420-DEN.). Englivioad,Cas'Scieliee Applications, 1980;

z o

A tW90d. PM X. CoknitiVe *truatuies-ifi-oihe Com-jireheniiion, and.rjmetiiister. ro 'Annals., An investigA4m

computer 'ilebiiskAnst (Tech. Alescarr,

. /*inf. Itiaearch Inst4tUti ,foittheSciences; 1978.0'

" . .Y ;. 0'. ;. . ; '1

Barstow, Itriiivirediefbased 'firograin Amsterdam:. - -.

19?9

Bell; .1), ProgramMee,stelietiOlt, and..,Pr:OgraMming,:eitrois. Computer, .

Journal,: 1976, 19,. 13), 20?.20,6.

Bereiter, C.', & .Searmadaliai M. From conversation to composition:Instruction in a ,developmental process. In R. Glaser (Ed..),Advances ilistral s chow (Vol. 2). Hillsdale, NJ:Erlbaum, 1982.

Black, S. D., Levin, J. A., Mehan, H., & Quinn, C. N. a1 andnon-real time interactions Unraveling multiple threads of dis-course. Discourse Processes, 1983. In press.

Sonar, J. Natural problem solving strategies and programming lan-guage constructs. '1n s of the Fourth Annual ConferenceoftleaSofettssee Society, Ann Arbor, Michigan, August4-6, 1982.

32 35

,.

ti

/Sonar, J., & Soloway, E. Uncovering principles of novice program-ming. Yale University Department of Computer Science (Res.Rep. No. 240, November 1982. (To appear in the TenthSIGPLANSIGACT Symposium on the 'Principles of ProgrammingLanguages, Austin, Texas, January 1983)

nrooks, .R. E. Studying programmer behavior experimentally: Theproblem's of proper methodology. Communications' of the ACM,-1980, 23 (4) 207-213.

Brooks, R. E. Towards a' theory of the cognitive processes in com-puter programming. International ,JOurnal of Man-MachineStudies, 1977, 9, 737-751.

Brown, A. L. , Learning and development:, The problems of compati-bility, access, and induCtion. Human DelTILt,_..tmrd, 1982 25,

,Brorn, A. L. Metacognition, executive., control, self-regulation andotheiY Avon more ,mysterious mechanisms. In 'R. H,. Kluwe & F.E. Weinert (Ede,0',,MetacOinition2:FOffiratiOn and lerning..,, yeitGermany: rtualhainrner,' I181(a). ,press. :

BriniAr,,," 4. ,Lia.17iing to

A' ig*CliatikOsita -*Td;NJ: :Dell, .1983(b).

I Pr,

L liransford, 1?eirara,',:ft. Camplone, J. C.Learning ,%reineinbering, and 'Understanding In P. H. miutein

Vol. :Cognitive 'bevel-oppment ey,:'1983.

town 4! mileY, S. S. , The ,,develOpMent of strategies forstudying, texts. Child DeVeloiimentj,,1978, , 49, 1076-1088';

IttLrn. ..how, to ,, read. ;danger &Res,der ,meets author, brid in ,theBe; Newark,

Brown, J. S., & Burtrint R. B. Diagnostic models for proceduralbugs in basic mailaematical skills. Cognitive Science, 1978, 2,155-192. 1

Brown, J. S., & 'VanLehn, K. Repair Theory: A generative theory-of bugs in procedural skills. Cognitive Science, 1980, 4, 379-426.

Burton, R. B. DEBUGGY: Diagnosis of errors in basic mathematicsskills. In D. H. Sleeman & J. S. Brown (Eds.), Intelligenttutoring systems. London: Academic Press, 1981.

33

Card, S. K. , Moran, T. P. , & Newell, A . Computer text editing: Aninformation processing analysis of a routine cognitive skill.Cognitive Psychology-, 1980, 12, 32-74,

Carry, L. R., Lewis, C., & Bernard, J. E. fry3 chology of equationsolving: An information processing study. Austin, TX: Depart-ment of Curriculum and Instruction. University of Texas atAustin, 1979.

Case, R., & Kurland, D. M. A new measure for determining chil-,drenis sUbjective organization of speech. Journal of Experi-mental Child Psychology, 1980, 30, 206-222.

Case, R., Kurland, D. M., & Goldberg, J. Operational efficiencyand the growth of short-1erm memory span. Journal of Exper-mental Child Psychology, 1982, 33, 386-7404.

Chase, W. G., & Simon, H. A. Perception in chess. CognitivePsychology, 1973, 4, 55-81.

Chi M.), T. H., Feltovich, P. J., & Glaset, R.,.

Categorization andreiresentation- of physics , problems by experts and novices.Cognitive Science, 1981, 5, 121-152'.

Chipmans:S., Siegel, 3., & Glaser, R. (Eds..). 'Thinkin and learn-in skills Cu rent research and"o Uestions. lilltdale, NJ:Erl aura, 1983, in

Clement, J., lacichhead, 3., & Monk, G. Translation difficulties inlearning mathematics (Tech. Rep.). Amherst, MA's CognitiveDevelopment PrOject$ Department of Physics and Astronomy,University of Massachusetti, 1979.

Cromer, R. F. The development of language and cognition: Thecognition hypothesis. In B. Foss (Ed.), New perspectives inchild development. London, England: Penguin, 1974, pp. 184-252.

.!I

Crystal, D. A first dictionary of linguistics and phonetics. NewYork: Cambridge University Press, 1980.

Curtis, B., Sheppard, S. B., Milliman, P., Borst, M. A., &

Love, T. Measuring the psychological complexity of softwaremaintenance tasks with the Halstead and McCabe metrics. IEEETransare Engineering, 1979, SE-5 (2), 96-104.

r.

DeKjeer, J., & Brown, J.and their acquisition.and their acquisition.

S. Mental models of physical mechanismsIn J. R. Anderson (Ed.), unitive skillsHillsdale, NJ: Erlbaum, 1981.

Dewey, J. The school, and society. Chicago: University of ChicagoPress. 1900.

Dijkstra, E. W. Goto statement considered harmful. Communications'of the ACM 1968, 147-148.

Dijkstra, E. W. . Englewood Cliffs, NJ:Prentice-Hall, 1976.

S.

DiPersioi T., Isbister, D., &' Shneiderman, B. An usingmemorization /reconstruction,. as a measure of prograMmer, ability.International Journal. of Man-Machine Studies, ,,1980, 13, 339-354.

biSessa, A. 'A. Unlearning Aristotelian physics: A study of know!-edge-based leainini. Cognitive Science, 1982,\,6, 37-75.

dutoulay,' 1.13. H. Teaching,' teachers:,.mathematics through 'program-ming. . International -Journal' of ,Mathematical Education. Scienceand Tethriology,.,1980, 11 (3). 347-360,.'

ii

duBoulay; J. 13, & O'Shea, I% How to work the Logo maqiine: 'Aprimer for 'ELOGO (D.A.I. Occasional PaPer 4). Edinburgh:Department of Artificial Intelligence, University Of Edinburgh,

0

1976.

duBoulay, J. B. H., & 'O'Shea, T. Seeing the works: A strategy forteaching interactive programming (D.A.I. Working Paper No.40). Edinlwrgh: Depirtment of Artificial Intelligence, Universityof Edinburgh, 1978..

duBoulay, J. B,. H., O'Shea, T., & Monk, J. The black box insidethe glass box: Presenting computing concepts to novices.International Journal of Man-Machine Studies, 1981, 14, 237-249.

Dwyer, T. A. Soloworks: Computer based laboratories for highschool mathematics. Science and Mathematics, 1975, 93-99.

Ehrlich, IC. & Soloway, E. An empirical investigation of the tacitplan knowledge in programming. In J. Thomas & M. Schneider(Eds.), Human factors in computer systems. Norwood, NJ:Ablex, 1983.

5; )4 38.0

35

;,

Eisenstadt, M., & Laubsch, J. H. Towards an automated debuggingassistant for novice programmers. Proceedings of the AISB-80Conference on Artificial Intelligence, Amsterdam, The Nether-lands, 1980.

Eisenstadt, M., Laubsch, J. H., & Kahney, J. H. Creating pleasantprOEatt/Loienvizonments for cognitive science students,. Paperpresented at the meeting of the Cognitive Science Society,Berkeley, CA, August 1981.

Feurzeig, W., Horwitz, P., & Nickerson, R. S. Microcomputers ineducation (Report No. 4798).. Prepared for: Department ofHealth, Education, and, Welfare; National Institute of Education;and Ministry for the Development of Human Intelligence, Republicof Venezuela. Cambridge, MA: Bolt Beranek and Newman,October 19,81.

Feurzeig, W., Papert, S., Bloom, M,, Grant,, R., & Solomon, C.programminglanguages as, a 'conceptual framework for teachingMathematics (Report. No. 1899). Cambridge, MA: Bolt Beranekand-Newman, 1969.

Flavell, , 4 braguns, j.. A' microgenetic -approach to' perception*and thought,. 12WholOgicalBulletifi, 1957, 54, 197-217.

Floyd, R. Wi ,,,The paradigms of programming. Communications of ti*ACM, 1979, 22 (8), 455.-460.

Friedman, W. J. (Ei.). The develoymtalparIckgy___)of time. NewYork: Academic Press, 1982.

Goldin, S. E., &. Hayes-Roth, B. Individual differences in planningprocesses. N-1488-0NR: A Raild Note, June 1980.

Goldstein, I., & Papert, S. Artificial intelligence, language, and thestudy of knowledge. Co 1977, 1, 84-123.

Gould, J. D. Some psychological evidence on how people debugcomputer programs. International Journal of Man-MachineStudies, 1975, 7, 151-182.

Gould, J. D., & Drongowski, P. An exploratory investigation ofcomputer program debugging. Human Factors, 1974, 16, 258-277.

Green, C. C., & Barstow, D. On program synthesis knowledge.Artificial Intelligence, 1978, 10 (3), 241-279.

3639

Harvey, B. Why Logo? Byte, 1982, 7, 163-193.

Hawkins, J., & Fiess, K. Illeeffnin experience on.children's conceptions of computer functioniu. (Tech. Rep.No. 19). New Yorks Center for Children & Technology, BankStreet College, May 1983.

Hawkins, J., Sheingold, K., Gearhart, M., & Berger, C. The impactof computer activity on the social experience of classrooins.Journal of Applied Developmental Psychology, 1983, 2. Inpress.

Hayes, J. R., & Simon, H. A.problem isomorphs. In N. J.G. R. Potts (Eds.), CognitiveErlbaum, 1977.

Psychological differences. amongCastellani. Jr., D. B.. 'Pisoni, &

theory. (Vol. 2). Hillsdale, -NJ:

Hayes-Roth, B. Estimation of time requirements during planning:The interactions between motivation and cognition. N1581-0NR.:A: Rand Note, November 1980.

.

Hayes-Roth, B.. & Hayes-Roth, F. A cognitive model of planning.Cognitive Science, 1979, 3, 275-310..

Hoc, J. , M. Role of mental representation in, learning a programming.language. International Journal of Man-Machine StUdies',' 1977,'9, 87 -105.

Howe, J. A. M. Developmental stages in learning to program. InF.. Klix & J. Hoffman (Eds.) , Cognition, and memory: Interdisci-plinary research of human memory activities. Amsterdam: North-Holland, 1980.-

Howe, .7. A. M. Learning mathematics through Logo programming(Research Paper No. 153). Edinburgh: Department of ArtificialIntelligence, University of Edinburgh, 1981.

Howe, J. A. M., O'Shea, T., & Plane, F. Teaching mathematicsthrough Logo programming: An evaluation study. In R. Lewis &E. D. Tagg (Eds.), Computer-assisted learning -- scope, progressand limits. Amsterdam: North-Holland, 1979.

Inhelder, B., & Piaget, J. inigrath of 12. ical thinking fromchildhood to adolescence (A. Parsons & S. &Ingram, Trans.).New Yorks Basic Books, 1958.

37

1

tyr....

Inhelder, B., Sinclair, H., & Bovet, M. Learning and the develop-ment of cognition. Cambridge, MA: Harvard University Press,1974.

Jeffries, R. A comparison of the debugging behavior of expert andnovice programmers. Paper presented at the annual meeting ofthe American Educational Research Association, New York City,March 1982.

Johnson, W. L., Draper, S., &fication scheme must takeceedings of the WorkshopCalifornia, 1983.

Soloway, E. An effective bug classi-the . programmer into account. Pro -on High-Level Debugging, Palo Alto,

Kahney, H., & Eisenstadt, M. Programmers' mental models of theirprogramming tasks: The interaction of real-world knowledge andprogramming knowledge. Proceedings of the Fourth AnnualConference of the Cognitive Science Societ , Ann Arbor, MI,August. 4-6, 1982.

Kamii, C. Pedagogical principles derived from Piaget's theory: Rele-Vance for educational practice. In M. Schwebel & J. Raph(Eds.'), Piaget in the classroom. London: Routledge & KeganPaul, 1974.

Kidder, T. The soul of a new machine. Boston: Little, Brown,1981.

Kurland, D. M., & Pea, R. D. Children's mental models of recursiveLogo programs (Tech. Rep. 10) . New York: Center for Chil-dren & Technology, Bank Street College, February 1983. Pre-sented at the 5th Annual Meeting of the Cognitive Science Soci-ety, Rochester, N.Y., May 1983. (To appear in Proceedings)

Laboratory of Comparative Human Cognition. Culture and cognitivedevelopment. In P. H. Mussen (Ed.), Handbook of child psy-chology. Vol. 1: History, theory, and methods (4th ed.) . NewYork: Wiley, 1983.

Laboratory of Comparative Human Cognition. Microcomputer communi-cation networks for education. The Quarterly Newsletter of the

boratory of Comparative Human Cognition, April 1982, 4 (2).

Larkin, J. H.', McDermott, J., Simon, D. P. & Simon, H. A. Expertand novice performance in solv:ng physics problems. Science,1980, 2c8, 1335-1342.

41

'1:q044,t5!Ig,)0,14;.,

Lawler, R. W. Extendinca powerful idea (Logo Memo No. 58).Cambridge, MA: MIT Artificial Intelligence Labo-atory, July1980.

Levin, J. A., & Kareev, Y. Personal computers and education: Thechallenge to schools (CHIP Report No. 98). La Jolla, CA:Center for Human Information Processing, 1980.

Lewis, C. Skill in algebra. In J. R. Anderson (Ed.), Cognitiveskills and their ac tion . Hillsdale, NJ: Erlbaum, 1981.

Lochhead, J. An anarchistic approach to teaching problem solvingmethods. Paper presented at the Annual Meeting of the Ameri-can Educational Research Association, San Francisco, April 1979.

Mann, W. C. Why things are so bad for the computer-naive user.Information Sciences Institute, March 1975.

Matz, M. Towards a process model of high school algebra errors. InD. H. Sleeman '& J. S. Brown (Eds.), Intelligent tutoring sys-tems. London: Academic Press, '.981.

Mayer, R. E. Different problem solving competencies established intlearning computer programming with and withe-it meaningful'models. Journal of Educational Psychology, 1975, 67, 725-734.

Mayer, R. E. A psychology of learning BASIC. Communications ofthe ACM, 1979, 22, 589-593.

Mayer, R. E. The psychology of learning computer programming bynovices. Com utixSurveys, 1981, 13, 121-141.

Mayer, R. E. Some conditions of meaningful learning for computerprogramming: Advance organizers and subject control of frameorder. Journal of Educational Psychology, 1976, 68, 143-150.

Mayer, R. E., & Bayman, P. Psychology of calculator languages: Aframework for describing differences in users' knowledge.Communications of the ACM, August 1981, 24 (8), 511-520.

McKeithen, K. B., Reitman, J. S., Rueter, H. H. , & Hirtle, S. C.Knowledge organization and skill differences in computer pro-grammers. Cognitive Psychology, 1981, 13, 307-325.

Miller, G. A., & Johnson-Laird, P. N. Language and per eption.Cambridge, MA: Harvard University Press, 1976.

42 39

Miller, L. A. Programming by non-programmers. InternationalJournal of Man-Machine Studies, 1974, 6, 237-260.

Milner, S. The effects of computer programming on performance inmathematics. ERIC Report No. ED076391, 1973.

Minsky, M. Form and content in computer science. Communicationsof the ACM, 1970, 17 (2), 197-215.

Moher, T., & Schneider, G. M. Methodology and experimental re-search in software engineering. International Journal of Man-Machine Studies, 1982, 16, 65-87.

Monk, G. S. Constructive calculus. Seattle: University of Washing-ton, 1978.

Moran, T. P. The command language grammar: A representation forthe user interface of interactive computer systems. InternationalJournal of Man-Machine Studies, 1981, 15, 3-50.

National Assessment of Educational Progress (1980) . Proceduralhandbook: 1977-78 mathematics assessment. Education Commis-sion of the States, Denver, Colorado.

National Institute of Education. Demands and cognitive consequencesof computer learning. Request for proposal NIE-R-82-0011, July1482.

Newell, A. One final word. In D. T. Tuma & F. Reif (Eds.),Problem solving and education. New York: Halsted Press, 1980.

Newman, W. M., & Sproull, R. F. Principles of Interactive ComputerGraphics (2nd ed.). New York: McGraw-Hill, 197V.

Nickerson, R. S. Thoughts on teaching thinking. EducationalLJadership, October 1981(a).

Nickerson, R. S. Why interactive computer systems are sometimesnot used by people who might benefit from them. InternationalJournal of Man-Machine Studies, 1981(b), 14, 469-481.

Nisbett, R. E. , & Ross, L. uman ii_ifetrld short-of social judgment. Englewood Cliffs, NJ: Prentice-Hall,

1980.

Norcio, A. F., & Kerst, S. M. Human memory organization forcomputer programs. Human Factors. In press.

40 43

Papert, S. Mindstorme. New York: Basic Books, 1980.

Papert, S. Teaching children thinking. Programmed Learning andEducational Technology, 1972(a), 9, 245-255.

Papert, S. Teaching children to be mathematicians versus teachingabout mathematics. International Journal for Mathematical Educa-tion, Science and Technology, 1972(b), 3, 249-262.

Papert, S., Watt, D., diSessa, A., & Weir, S. An assessment anddocumentation of a children's computer laboratory. Final Reportof the Brookline Logo Project, Blsook line, Massachusetts, 1979.

Pea, R. D. Programming and problem solving: Children's experiencewith Logo. Paper presented at a symposium, "Chameleon in theclassrooms Developing roles for computers," annual meetings ofthe American Educational Research Association, Montreal,Canada, April 1983. (Also Technical Report No. 12, Center forChildren and Technology, Bank Street College of Education)

Pea, R. D. What is planning development the development of? InD. Forbes & M. , Greenberg (Eds.), New directions in childdevelopment: Children's planning strategies (Vol. 18). SanFrancisco: Jossey-Bass, December 1982.

Pea, R. D., & Hawkins, J. A microgenetic study of planning proc-esses in a chore-scheduling task. In S. L. Friedman, E. K.Scholnick, & R. R. Cocking (Eds.), Blueprints for thinking:The development cognitive planningr skills. NewYork: Cambridge University Press, 1983. In press..

Pea, R. D., Hawkins, J., & Sheingold, K. Developmental studies onlearning Logo 'computer programming. Paper presented at theannual meetings of the Society for Research in Child Develop-ment, Detroit, April 1983. (Also Technical Report No. 17,Center for Children and Technology, Bank Street College ofEducation).

Pea, R. D., & Kurland, D. M. Log ro ratgweini aiLaltdevelo -.:mitoL.21111Inin skills (Tech. Rep. No. 16). New York: Centerfor Children and Technology, Bank Street College, April1983(a).

Pea, R. D., & Kurland, D. M.

York: Center for ChildrenApril 1983(b).

4n the cognitive prerequisites oflearning computer program qng (Tech. Rep. No. 18). New

and Technology, Bank Street College,

41

Piaget, J. The child's conception of time (A.J. Pomerans, trans.) .New York: Ballantine, 1969.

Piaget, J. Intellectual evolution from adolescence to adulthood.Human Development, 1972, 15, 1-12.

Price-Williams, D., Gordon, W., & Ramirez, M. Skill and conserva-tion: A study of pottery-making children. Developmental Psy-chology, 1969, 1, 769.

Reitman, J. S., & Rueter, H. R. Organization revealed by recallorders and confirmed by pauses. unitive P,s cly.....221m, 1980,12.

Resnick, L. B. Task analysis in instruction design: Some cases frommathematics. In D. Klahr (Ed.), Cognition instrtisgs.Hillsdale, NJ: Erlbauth 1976, pp. 51 -80.'

Rich, C., & Shrobe, H. E. Initial report on a Lisp programmer's ap-prentice. IEEE Transactions on Software Engineering, 1978,SE-4, 456-467.

Ross, P., it Howe, J. Teaching mathematics through programming:Ten year on. In R. Lewis & D. Tagg (Eds.), Computers ineducation. Amsterdam: North-Holland, 1981.

Rumelhart, D. E. Schemita: The building blocks of cognition. InR. J. Spiro, B. C. Bruce, & W. F. Brewer (Eds.), Theoreticalissues hi reading comprehension: Perspectives from cognitivepis chologx,' linguistics, artificial intelligence, and edtcation.Hillsdale, NJ: Erlbaum, 1980.

Sackman, H. Man- computer problem solving. Princeton, NJ: Auer-bach, 1970.

Schank, R. Dynamic Memory.Press, 1982.

New York: Cambridge University

Schank, .&Hillsdale,

EPr.

lbaSucm, 1977.Scripts, under-

Seidel, R. J., Anderson, R. E., & HunterIssues and directions for 1985. New1982.

B. Computer literacy:York: Academic Press,

Shell, B. A. Coping with complexity. Cognitive and InstructionalSciences Series, April 1981(a), CIS-15.

42 45

Sheil, B. A. The psychological study of programming. ComputingSurveys, March 1981(b), 13 (1).

Sheil, B. A. Teaching procedural literacy. Proceedings of ACMAnnual Conference, 1980, pp. 125 -126,

Sheingold, K., Kane, J., Endreweit, M., & Billings, K. Study ofissues related 'to the implementation of computer technology inschools. Final Report, National thstitute of Education, 1981.(Also Technical Report No. 2, Center for Children and Technol-ogy, Bank Street College of Education)

Sheppard, S. B., Curtis, B., Millman, P., & Love, T. Moderncoding practices and programmer performance. IEEE Computer,1979, 5 (2), 41-49.

Shif, Z. I.In M.Soviet

Development of children in schools for mentally retarded.Cale & I. Maltzman (Eds.) , A handbook orarpsychology. New York: Basic Books, 1969.

Shneiderman, B. Measuring computer program 'quality and compre-hension. International Journal of Man-Machine Studies, 1977, 9,465-478.

Shneiderman, B., & Mayer, R. Syntactic/semantic interactions inprogrammer behavior: A model mad experimental results. Inter--national Journal of Cuter and Information Sciences, 1979, 7,219-239.

Shrobe, H. E., Waters, R., & Sussman, G. A hypothetical monologueillustratin the knowled e of underl in ro ram anal sis (MemoNo. 507). Cambridge, MA: MIT Artificial Intelligence Labora-tory, 1979.

Shweder, R. A. Likeness and likelihood in everyday thought: Magi-cal thinking and everyday Judgments about personality. CurrentAnthropology, 1977, 18, 637-658.

Sime, M. E., Arblaster, A. T., & Green, T. R. G. Reducing pro-gramming errors in nested conditionals by prescribing a writingprocedure. International Journal of Man-Machine Studies, 1977,9, 119-126.

Simon, H. A. Problem solving and education. In D. T. Tuma &F. Reif (Eds.), Problem solving and education: Issues in teach-ing and research. New York: Halsted Press, 1980.

Simon, H. A., & Hayes, J. R. The understanding process: Problemisomorphs. Cognitive , 1976, 8, 165-190.

Smith, E. E., & Bruce, B. 'C. An outline of a conceptual frameworkfor the teaching of thinking skills (Report No. 4844). Preparedfor National Institute of Education. Cambridge, MA: Bolt Bera-nek and Newman, 1981.

Sole .say, E., Bonar, J., & Ehrlich, K. Cognitive strategies andlooping constructs: An empirical study. Communications of theAM, 1983. In press.

Soloway, E., & Ehrlich, K. Tacit programming knowledge. Proceed-in s of the. Fourth Annual Conference of the Co nitive ScienceSociety, Ann Arbor, Michigan, August 4-6, 1982.

Soloway, E., Ehrlich, K., Bonar, J., & Greenspan, J. What donovices 'know about programming? In B. Shneiderman &

A. Badre (Eds.) , Directions in human - commuter interactions.Hillsdale, NJ: Ablex, 1982.

Soloway, E., Lochhead, J., & Clement, J. Does computer program-ming enhance problem solving abilityt Some positive evidence onalgebra word problems. In R. *Seidel, R. Anderson, & B.Hunter (Eds.), am literacy: Issues and directions for1985. New Yorks Academic Press, 1982.

Soloway, E., Rubin, E., Woolf, B., Bonar, J., & Johnson, W., L.MENO-III An AI-based programming tutor. Yale University,Department of Computer Science (Res. Rep. No. 258, December1982.

Spiro, R. J., Bruce, B. C., & Brewer, W. F. (Eds.), Theoreticalissues in reading comprehension. Hillsdale, NJ: Erlbaum, 1980.

Statz, J. Problem solving and Logo. Final report of Syracuse Uni-versity Logo Project, Syracuse University, New York, 1973.

Sternberg, R. J., & Rifkin, B. The development' of analogical rea-soning processes. Journal of Experimental Child Psychology,1979, 2 ?, 195-232.

Thayer, R. H., Pyster, A. B., & Wood, R. C. Major issues insoftware engineering project management. IEEE Transactions onSoftware ineerin , 1981, SE - ?, 333-342.

Tobias, S. Overcoming math anxiety. New York: Norton, 1978.

44 47

Tama, D. T., & Reif, F. (Eds.). Problem solving and education:Issues in teaching and research. New York: Halsted Press,1980.

Tveisky, D., & Kahneman, D. Science, 1980, 211.

VanLehn, K. Bugs are not enough; Empikrical, studies of bugs,impasses and repairs in procedutal skills. Xerox Cognitive andInstructional Sciences Series, March 1981, CIS-11.

Ward, W. C., & Jenkins, H. M. The display of information ,and thejudgment of contingency. Canadian Journal of Psychology, 1965,19, 231-241.

.Waters, R. ,The programmer's apprentice: Knowledge based .pro-gram editing. IEEE Transactions on Software Enlineering, 1982,SE-8 (1).

Watt, D. Logo in the schools.. Rita August 1982 7 (8), 116-134.

Weir,' S. Logo as an Anfoimat(ion prosthetic for.vhandicapped.(Working paper ,,NO. WP-9).i- Cambridge, MA: ':MIT, Division forStudies and Research in 'EdtOation, May -1981.

Weir, S., b Watt, D. Logo: Al computer environment for learning7disabled students. The''Corpputer Teacher, 1981, 8 (5) 11-17.

Weizenbaum, J. CoMputer power and ,human reason: From judgmentto calculation. San Francisco: Freeman, 1976.

Werner, H. The concept of development from a comparative" andorganismic point of view. In D. R. Harris ,(Ed.), The conceptor f development. Minnesota: University of Minnesota Press, 1957.

Werner, H. Process and achievement. Harvard Educational Review,1937, 7, 353-368.

Young, R. M. The machine inside the machine: Users' models ofpocket calculators. International Journal of Man-MachineStudies, 1981, 15, 51-85.

Youngs, E. A. Human errors in programming. International Journalof Man-Machine Studies, 1974, 6, 361-376.

48 45