HAL Id: hal-00190531
https://telearn.archives-ouvertes.fr/hal-00190531
Submitted on 23 Nov 2007
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
On the Cognitive Prerequisites of Learning Computer Programming
Roy D. Pea, D. Midian Kurland
To cite this version:
Roy D. Pea, D. Midian Kurland. On the Cognitive Prerequisites of Learning Computer Programming.
1983. �hal-00190531�
On the Cognitive Prerequisites of Learning Computer Programming
Roy D. Pea D . Midian Kurland
Technical Report N o . 18
ON THE COGNITIVE PREREQUISITES OF LEARNING COMPUTER PROGRAMMING*
Roy D. Pea and D . Midian Kurland
Introduction
Training in computer literacy of some form, much of which will consist of training in computer programming, is likely to involve $3 billion of the $14 billion to b e s p e n t on personal computers by 1986 (Harmon, 1983). Who will do t h e training? "hardware a n d software manu- f a c t u r e r s , management consultants, - r e t a i l e r s , independent computer instruction centers, corporations' in-house training programs, public and private schools a n d universities, and a variety of consultants1'
(ibid.,
-
p . 2 7 ) . To d a t e , very little is known about what one needs to know in order to learn to program, and t h e ways in which edu- cators might provide optimal learning conditions. The ultimate suc- cess of these v a s t training programs in programming--especially toward the goal of providing a basic computer programming compe- tency for all individuals--will depend to a g r e a t degree on an ade- quate understanding of t h e developmental psychology of programming skills, a field c u r r e n t l y in i t s infancy. In t h e absence of such a theory, training will continue, guided--or to e x p r e s s i t more aptly, misguided--by t h e tacit Volk theories1' of programming development that until now have s e r v e d as the underpinnings of programming instruction. Our p a p e r begins to explore t h e complex agenda of issues, promise, and problems that building a developmental science of programming entails.Microcomputer Use in Schools
The National Center for Education Statistics has recently released figures revealing t h a t the use of micros in schools tripled from Fall 1980 to Spring 1983. The outcome of that leap. is that there a r e now 120,000 microcomputers for students in 35% of t h e country's public
*The work upon which this publication is based was performed pursuant to Contract No. 400-83-0016 of the National Institute of Education. It does n o t , however, necessarily reflect the views of that agency.
schools: 22% of these a r e in elementary schools, and 64% are located in secondary schools (Reed, 1983). A staggering 4.7 million precol- lege students worked at computer terminals during the 1981-1982 school year. Yet t h e National Education Association reported in March 1983 t h a t just 11.2% of the country's public school teachers use computers in teaching.
Problems with Questions of the "Cognitive Demands" of Programming A common s e t of questions voiced b y those wishing to learn computer programming ( b u t p e r h a p s as commonly voiced b y those offering programming training o r courses) is: "What do I need to know in order to learn to prsgram?"Do I need to be good at mathematics?
If I'm not, can I still learn to program?" "Do I need to be a highly developed logical thinker?" h the academic community, these ques- tions get expressed in the jargon of the social sciences: "What a r e the cognitive demands of programming?" o r W h a t mental abilities a r e cognitive prerequisites for learning to program?" o r "Are there individual differences in programming skill development?" The com- mon dear for t h e individual who would Like to learn programming, and the concern of educators and employers (frequently motivated by cost effectiveness), i s that t h e r e a r e some persons who a r e either not capable of being trained to program, o r who a r e not "developmentally ready" t h a t they need to learn o r know more fundamentally rele- vant things before embarking on the task of learning to program.
While these questions a r e subject to empirical analyses, we have found in reviewing t h e literature that the uses of s u c h empirical analyses are often quite pernicious. If persons do not get a high enough score. on a "programming aptitude measure," they may be denied educational o r employment opportunities. One s t u d y is quite explicit on the uses to which they believe s u c h findings should be put--£or student advising and placement:
The rapid increase in the need for personnel in these areas is attracting many individuals needing education, and
-
the number who will not succeed with this education will in- crease...
.The increase in the number of s u c h s t u d e n t s is already being observed b y many schools, resulting in the use of relatively scarce faculty resources to educate indi- viduals who will not successfully complete a technical course, while keeping out students who might succeed if permitted to enroll. (Wileman. Konvalina & Stephens, 1981, p . 2 2 6 ; o u r emphases)Fowler & Glorfeld (1981, p . 96) note that " t h e need t~ identify a potentially successful student is very important for reasons such as
early counseling into an appropriate c a r e e r path and formation of honors section^.^ In another s t u d y , Newstead (1975, p . 89) goes so far as to say t h a t 'lone can conclude t h a t programming ability ( a s measured in t h i s s t u d y ) may be much more innate than 'business training course spiels' would have one believe. Anyone cannot be a programmer [ s i c ]
.
The logic of t h e s e approaches is not h a r d to follow. Let t h e rich get richer, while t h e poor recede into the nontechnical background of society. Never mind t h a t i t may be possible to i n s t r u c t "those who will not succeed" in another way (and the pedagogical alternatives for learning to program a r e many and diverse [Lemos, 1975, 1980;
Papert, 19801 ). I n s t e a d , assume that " t h i s education" t h a t they will not succeed with i s immutable and adequate f o r anyone wishing to learn to program only they had the r i g h t s t u f f . n While some may have felt t h a t t h i s a t t i t u d e had some justification when programming was an optional activity (something one could, b u t need not d o ) , i t i s a problem of g r e a t s e r i o u s n e s s today, since a t least a basic under- standing of (modicum of competence in) how to write and u n d e r s t a n d computer programs is a t t h e core of the needs for any member of a computer literate society ( e . g
. ,
Sheil, 1981a, 198 1 b ).
We cannotcontinue to dismiss those who have difficulties i n learning to program a s flies in t h e ointment of a well-oiled training machine. I n s t e a d , we a r e obliged to try o u t o r , if n e c e s s a r y , develop new means for in- struction t h a t allow a l l an equal opportunity to learn about and p a r - ticipate in the computational powers of a technological society, one which has an impact on a n d will continue to have an even g r e a t e r impact on t h e educational, work, and family lives of members of o u r society.
Overview In preparing the available
t h i s r e p o r t , we found that when we critically considered l i t e r a t u r e t h a t aims to a d d r e s s t h e relationships between nprogramming aptitude" and i n t e r e s t s of individuals and their pro- gramming performance, t h e static n a t u r e of t h e s e studies was a p p a r - e n t in that t h e r e s e a r c h questions asked have not varied substantially in nearly 30 y e a r s . ~ v k r since t h e 1950s. when the Programmer Aptitude Battery was developed by IBM to help select programmer trainees, consistently modest correlations ( a t t h e i r best from 0 . 5 to 0 . 7 , hence accounting for only a q u a r t e r to a half of the variance) , and in many cases much lower, have existed between an individual's score on such a measure and h s or h e r a s s e s s e d programming skill.
In addition, e v e r since the 1950s. global measures of programming skill, such as g r a d e in a programming training course or supervisor r a n h n g , have s e r v e d as s k d l assessments. Studies in 1983 still take
for granted the utility of this multivariate approach, and offer no greater insights--certainly none that a r e instructionally relevant--into what makes a successful programmer t h a n t h e y did t h r e e decades ago.
The same is t r u e of i n t e r e s t measures a n d programming skill assess- ments. These s t u d i e s always a s k whether particular ap titude vari- ables have an effect on programming s u c c e s s , r a t h e r than the more fundamental psychological question of how t h e y might have s u c h effects, in terms of component skills o r knowledge representations mediating specific programming activities.
Given these insufficiencies, we must often s t e p back during t h e course of our review a n d s u r v e y t h e presuppositions that have guided this Line of r e s e a r c h , asking whether t h e y a r e warranted, culling from the r e s e a r c h Literature t h e few s t u d i e s t h a t s u g g e s t new and promising directions, a n d asking many more questions than we a r e able to answer on t h e basis of available evidence. While the d e a r t h of answers to t h e s e questions i s at times disconcerting, we feel that a groundclearing i s in o r d e r . The available foundations a r e unstable, so we must uproot them in a s e a r c h f o r new metaphors, new ways of seeing what programming i s t h a t people may l e a r n to do i t , and what i t i s about people t h a t t h e y a r e able to do programming. Since t h e available programming a p t i t u d e l i t e r a t u r e is built upon such ques- tionable foundations, a point-by-point review of thls literature in terms of subject populations, specific measures, and correlations obtained is not useful, although we will provide brief surveys and extensive citations of t h e h u n d r e d o r so s t u d i e s of this k m d . On t h e other hand, we a r e heartened b y some recent s t u d i e s on the cognitive psychology of programming t h a t begin to unravel the complex of mental activities essential to programming. In o u r intellectual travels through the development of programming skills, we become more and more compelled b y t h e importance of one dominant motif: the role of purpose and goals in programming. What one needs to know in o r d e r to program will depend in fundamental ways on one's programming goals. This point has repercussions all the way from how one does programming i n s t r u c t i o n , to what kinds of programming instruction a r e selected on t h e basis of t h e educational values and goals t h a t define one's programming pedagogy. To t a k e a simple example:
documenting a program a n d t h e mental skills t h a t a r e required may be unnecessary for a single-use program for o n e s s home computer s y s - tem. But it is a c e n t r a l concern if one r e q u i r e s a program for t h e public domain t h a t is understandable and rnaintainabae b y o t h e r s . So w e will ask n o t , "What a r e the cognitive demands of computer pro- gramming?" as if programming were a unified homogeneous activity (which we challenge below ) , b u t r a t h e r , I' What a r e the cognitive demands of doing computer programming activity X with goal Y?"
With these provisos in mind, we will now begin to develop the ground raising which we have promised.
Background Issues What Is Computer Programming?
We will define the core sense of ncomputer programming" as that s e t of activities involved in developing a reusable product consisting of a series of written instructions that make a computer accomplish some task. It is interesting to note t h a t , although the sense of "computer programming" has not varied in nearly four decades, the set of activities involved in doing programming has undergone major quali- tative transformations. In t h e early days of programming, for ex- ample, the programmer had to know t h e details of the computer hardware in order to write a program that worked; today this is no longer true. An important consequence of this evolution of the set of activities that constitutes programming is that t h e "cognitive demands"
made by computer programming needs specification at the level of programming s u b t a s k s , o r component activities. Therefore, we must ask about the variety of cognitive activities involved in computer pro- gramming as it i s carried out today, and especially as i t i s carried out by children as they attempt to master this complex skill.
From our own work a s well a s our reading in the literature on pro- gramming, we find t h a t a t least four distinct levels of computer pro- gramming ability can be identified. While these levels represent pure types and a r e not characteristic of a single individual, they do cap- ture some of t h e compleldty of what it means to learn to program.
While we will take u p t h e issue of levels of programming skill devel- opment in more detail below, i t is important in attempting to build an adequate characterization of t h e programming process to bear in mind the range of abilities included under the heading of "being able to program.
Level I: Program u s e r . Before learning how to program, one typically learns to execute already written programs such as games, demonstrations, o r
CAI
lessons. What is learned at this level is not' trivial (i. e . , what t h e r e t u r n key or the reset key does, how to boot a disk, how to use a screen menu), but gives no information to the novice on how a computer program works o r even that there is a program controlling what happens on the screen. Many adult com- puter users never advance past this level. One does not need to know about programming to be a word processor operator, make airline reservations, process payroll checks, design a budget, or do any of a growing number of computer-based activities. However,Level I users remain a t t h e mercy of the program they a r e using and are powerless to effect changes in i t . While i t can be argued that a s programs get b e t t e r , t h e r e will be less need f o r the average person to make programming changes, we would a r g u e t h a t without some familiarity with programming, the user is less likely to appreciate fully the power and potential of this technology. In addition, without some appreciation of programming, the u s e r is not likely to take full advantage of optional parameters built into sophisticated application programs which themselves constitute a high-level form of program- ming.
Level
LI:
Code generator. At this level the s t u d e n t knows the syntax and semantics of t h e more common commands in a language.The user can r e a d someone else's program and know what each line accomplishes. The s t u d e n t can locate bugs that p r e v e n t commands from being executed (e. g.
,
syntax e r r o r s ) , can load and save pro- gram files to a n d from a n external storage device, and can write simple programs t h a t h e o r s h e has seen previously. When program- ming, the s t u d e n t does v e r y little preplanning and does not both& to document his o r h e r program. There is no effort to optimize t h e coding, use e r r o r t r a p s , o r make the program user-friendly and crash resistant. A program a t this level might simply consist of printing the s t u d e n t ' s name over and over on t h e screen or drawing the same shape repeatedly in different colors. The s t u d e n t operates at the level of t h e individual command and does not u s e subroutines o r procedures created a s p a r t of other programs.Level
III:
Program generator. At this level, the student has mastered the basic commands and is thinking in terms of higher level units. Sequences of commands that accomplish program goals a r e known (e.g., locate and verify a keyboard i n p u t , s o r t a list of names o r numbers, r e a d data into a program from a separate file). The student can now r e a d a program and say what t h e goal of the pro- gram i s , what functions different p a r t s of the program s e r v e , and how the different p a r t s a r e linked together. The s t u d e n t can locate bugs that p r e v e n t t h e program from functioning properly (e. g.,
a sort routine t h a t fails to correctly place the last item in a list) o r bugs which cause the program to c r a s h as a result of unanticipated conditions o r i n p u t s (e. g.,
a division by zero e r r o r when the pro- gram is instructed to find the mean of a null l i s t ) . The student can load, save, and merge files, and can do simple calls to and from files inside the main program. The student may be writing fairly lengthy programs for personal u s e , but the programs tend not to be user- friendly. While the s t u d e n t sees the need for documentation, he o r she does not plan programs around the need for careful documentation so that the program may be maintained b y others. Within this gener-a1 level, one can identify many sublevels of computer programming slull
.
Level IV: Software developer. At t h s level, the s t u d e n t i s ready to write programs t h a t a r e both complex and a r e intended to be used by o t h e r s . The s t u d e n t now knows several languages and has a full understanding of all t h e i r f e a t u r e s and how the languages inter- act with the host computer ( e . g . , how memory is allocated, how graphic buffers can b e protected from being overwritten, how periph- eral devices can be controlled b y the p r o g r a m ) . When given pro- grams to r e a d , the s t u d e n t can scan the code and simulate mentally what the program i s doing, see how the goals are achieved a n d , most likely, how the programs could be b e t t e r written or adapted for o t h e r purposes. The s t u d e n t now writes programs with sophisticated e r r o r t r a p s and built-in t e s t s to aid in t h e debugging process and to e n s u r e that the program will b e reliable, provable, and maintainable.
In addition to writing code t h a t accomplishes the program's objective, the s t u d e n t can optimize coding to increase speed and minimize the amount of memory r e q u i r e d for r u n n i n g . To decrease t h e time needed to write programs, t h e s t u d e n t will draw heavily on software libraries and programming utilities. Finally, t h e s t u d e n t will often design t h e program before generating the code,' will document the program fully, and will write t h e program in a s t r u c t u r e d fashion t h u s malung i t easy for others to r e a d a n d / o r modify. Major issues in software engineering at t h i s level of e x p e r t i s e a r e discussed by T h a y e r , Pyster and Wood (1981).
There a r e many methodological problems with assessing computer programming abilities a c r o s s these four major levels and their many sublevels. While psychological studies of e x p e r t and novice pro- grammers have revealed some efficient measures t h a t exploit t h e differences in programming-specific problem-solving strategies--spe- cifically , debugging ( J e f f r i e s , 1982) and program memory organization
(diPersio et a l . , 1980)--determining whether o r not a person can program at some specified level of expertise remains a difficult t a s k . Demands of Learning to Program: The Problem of Differentiation
The question of t h e cognitive demands of computer programming is an enormously complex o n e , because nprogrammingn is not a u n i t a r y s h l l . Like r e a d i n g , i t i s comprised of a large number of abilities that interrelate with t h e organization of the l e a r n e r ' s knowledge b a s e . memory and processing capacities, repertoire of comprehension strate- gies, and general problem-solving abilities. In addition, a program- mer may be highly developed in some aspects of programming but not in o t h e r s . For example, i t is not uncommon to find programmers who
can write highly efficient and elegant code, b u t not code that can be understood o r maintained by other programmers. Typically, in r e - search on the psychology of computer programming, "learning to program" has been equated with learning t h e s y n t a x and the defini- tion of commands in a programming language, just as reading is often equated with skill in decoding. However, once past the initial level of skill acquisition, what we mean by "readingn i s actually reading comprehension, which entails a n elaborate body of world knowledge, comprehension monitoring, inferencing
,
hypothesis generation, and other cognitive and metacognitive strategies that take years to devel- op fully. This lesson has been etched in high relief through the intensive efforts necessary to develop artificial intelligence systems that "understandn t e x t (e. g. ,
Anderson & Bower, 1973; Schank, 1982; Schank & Abelson, 1977). Skilled reading also requires wide experience with different types of texts (e. g. ,
narrative, essays, plays, poetry, debate, biography) and with different goals of the reading activity ( s u c h a s reading f o r meaning, content, style, pleas- u r e ) . Skilled computer programming is similarly complex and context- dependent, which makes the problem of assessing the cognitive de- mands of nlearning to program'' all the more acute.This issue of "cognitive demandsn and the corresponding problem of selecting components of t h e question that a r e researchable has been a general one. The idea that some development may s e r v e as a neces- s a r y prerequisite for some other development i s familiar from the Literature of moral reasoning (e. g
. ,
Tomlinson-Keasey & Keasey , 1974), language development ( e . g i , Sinclair, 1969; Slobin, 1973, 1982) and, more generally, from the "invariantn developmental stage sequence arguments offered by Piaget as central to his structuralist developmental theory. This approach to the cognitive demands of programming h a s recently begun to be applied to programming as well (Favaro, 1983). In each case, the empirical testing of the prereq- uisite character of some specific cognitive achievement for some other cognitive achievement has depended on a refinement of the general question into specific questions t h a t a r e empirically researchable.Rather than asking, a s in the early days of the cognitive prerequisite controversy in developmental psy cholinguistics--I1 Daes language learn- ing require prior concept development for the ideas expressed in language?"--current language development research recognizes that such a question must be asked for specific language constructions o r s u b p a r t s of language, and that the answer will depend on the lin- guistic forms chosen ( e . g . , Johnston, 1 9 8 2 ) . W e will u r g e a similar differentiation for questions about the "cognitive demands" o r "pre- r e q u i s i t e s b f learning to program--cognitive prerequisites in o r d e r to do what specifically in programming?
What Programming Is a s a Cognitive Activity
In this section, we first outline recent findings about the cognitive psychology of e x p e r t programming, then provide a brief account of available theories of t h e cognitive s u b t a s k s involved in programming, describe existing accounts of what "learning to program" involves, and then critique t h e popular accounts of what learning to program requires.
One can begin to analyze what programming skill is as a cognitive activity by engaging in detailed analyses of what expert programmers do, and what kinds and organizations of knowledge they appear to
-
have stored in memory in o r d e r to do i t . This research s t r a t e g y has revealed significant general features of e x p e r t problem-solving com- petence and performance for a wide variety of other subject domains such as algebra (Lewis, 1981), chess (Chase & Simon, 1973), geome- try (Anderson, Greeno, Kline & Neves, 1981), physics (Chi, Felto- vich & Glaser, 1981; Larkin, McDermott, Simon & Simon, 1980), physical reasoning (deKleer & Brown, 1981), and writing (Bereiter &Scardamalia, 1982), a n d i t has begun to provide some insights into the components of programming skill.
Recent studies of programmers suggest that high-level computer programming skill is characterized by a giant assembly of highly specific, low-level knowledge fragments (Brooks, 1977; Atwood &
Ramsey
,
1978). For example, the design of functional "programmer's apprenticesn s u c h a s Barstow's (1979) Knowledge Based Program Construction, and Rich and Shrobe's "Lisp programmer's apprentice"(Rich & Schrobe, 1978; Shrobe, Waters & Sussman, 1979; Waters, 1982), and t h e MEN0 Programming Tutor (Soloway, Rubin, Woolf, Bonar & Johnson, 1982) h a s involved compiling a "plan library" of the basic computer programming schemas
,
I' o r r e c u r r e n t functional chunks of programming code that programmers a r e alleged to use.There is some behavioral evidence from studies of programmers that supports these rational and introspective analyses of "chunks" of computer programming knowledge. Eisenstadt, Laubsch and Kahney (1981) have developed a Logo-like software programming language called SOLO and used i t to introduce computer-naive college psychol- ogy students to computer programming. In a n analysis of novice student programs, they found that most programs were constructed from a small s e t of basic program schemas comparable to the "plan library" of Schrobe e t al. (1979). Jeffries ( 1 9 8 2 ) , in a comparison of the debugging strategies of novice PASCAL programmers and graduate computer science s t u d e n t s , found that " e x p e r t s saw whole blocks of code as 'instantiations' of well-known problems" such as " calculating change. I'
Soloway and his colleagues (Bonar, 1982; Ehrlich & Soloway, 1983;
Johnson, Draper & Soloway, 1983; Soloway & Ehrlich, 1982; Soloway, Ehrlich, Bonar & Greenspan, 1982; also see Kahney & Eisenstadt, 1982) have begun to construct a "plan-based theory of computer programming"which also p o s t d a t e s the use of r e c u r r e n t plans a s n c h u n k ~ " in program composition. Such plans were identified in preliminary analyses of programs written by PASCAL novices ( e . g . , the "counter variable p l a n " ) . What is missing h e r e , for our pur- poses, is a ~ e n e t i c account of the construction of s u c h plan schemas from programming instruction, experience, and prior knowledge that is brought to t h e t a s k of learning to program. (For the interested reader, a general account of schema theory in cognitive science is provided by Rumelhart, 1980. )
A second, related characteristic of computer programming skill is the large number of component rules that underlie an e x p e r t ' s generation of programming problem solutions. In an analysis of one program- mer's work on 23 different problems, Brooks (1977) demonstrated in a detailed model t h a t about 104 rules were necessary to generate the protocol behavior. F u r t h e r , Green and Barstow (1978) note that over a hundred r u l e s for mechanically generating simple sorting and searching algorithms- (e. g
. ,
Quicksort) a r e familiar to most pro- grammers.A third characteristic of computer programming skill is the ability to construct detailed mental models of how the computer is functioning when a computer program is running (Sheil, 1980, 1981a). The expert programmer can build dynamic mental representations, o r
"runnable mental modelsn (Collins & Gentner , 1981) in which they can simulate computer operations in response to specific problem i n p u t s . Brooks (1977) h a s characterized these mental operations as "symbolic e x e c u t i o n s . " T h e complexities of such dynamic mental models a r e revealed when skilled programmers gather evidence for program bugs and simulate t h e program's actions b y hand (Jeffries, 1982). We should note t h a t not a l l aspects of program understanding are medi- ated by hand simulation; often e x p e r t s engage in a prior global search for program organizational s t r u c t u r e , a s t r a t e g y akin to that of expert t e x t r e a d e r s (Brown, 1983b; Brown & Smiley, 1978: Spiro, Bruce & Brewer, 1980) and guided b y adequate program documenta- tion.
Expert programmers not only have more information about the com- puter programming domain, b u t remember l a r g e r , meaningful chunks of information t h a t enable them to perceive programs and remember them mote effectively than novice programmers. The classic Chase and Simon (1973) finding of short-term memory advantages for chess
e x p e r t s over novices f o r meaningful chessboard configurations b u t not for random configurations h a s been repeatedly replicated for the domain of computer programming ( C u r t i s , S h e p p a r d , Milliman, Borst &
Love 1979; McKeithen, Reitman, Rueter & Hirtle, 1981; Norcio &
erst,
in p r e s s ; S h e p p a r d , C u r t i s , Milliman & Love, 1979; Shneider- man, 1977). For example, McKeithen et al. (1981) used the Reitman- Rueter (1980) technique for inferring individual s u b j e c t s ' chunking of key ALGOL programming concepts in memory from recall o r d e r s to discover the specifics of memory organization t h a t may facilitate this performance difference. They found extensive differences in the mnemonic strategies u s e d by beginning, intermediate, and e x p e r t ALGOL programmers to memorize ALGOL keyword stimuli. Notably, e x p e r t s clustered t h e keyword commands according to meaning in ALGOL ( e . g . , those functioning in loop s t a t e m e n t s ) , whereas novices clustered according to a v a r i e t y of s u r f a c e o r d i n a r y language associ- ations ( s u c h as orthographic similarity and word l e n g t h ) , with i n t e r - mediates somewhere in between. In a related f i n d i n g , Adelson ( 198 1) presented computer programming novices and e x p e r t s with a recall task in which stimuli were lines of programming code which could be organized either procedurally (into programs) o r syntactically (in terms of o r d e r relationships between different control phrases of the computer language). She found t h a t e x p e r t s recalled program lines"in the o r d e r in which t h e y would have been evaluated in a running program,
"
whereas novices clustered by s y n t a c t i c category. Recall clusters for e x p e r t s were t h u s functionally o r "deeply" based, where- a s those of novices were based on "surface" f e a t u r e s of programming code. This distinction i s reminiscent of t h e s t r i k i n g developmental shift from surface s t r u c t u r e - b a s e d , or "syntagmatic ,"
word associa- tions to functional category-based, o r "paradigmatic," word associa- tions during childhood ( e . g. ,
Nelson, 1977).DiPersio, I s b i s t e r a n d Shneiderman (1980) have carried this line of research f u r t h e r b y demonstrating that performance on a program memorizationlreconstruction t a s k provides a useful measure and pre- dictor of computer programming ability. Scores on program logic reconstruction t a s k s a n d performance on college class exams in pro- gramming were significantly correlated. The a u t h o r s attributed this r e s u l t to the e x t e n t of subjects' "semantic" knowledge base for the programming language, t h a t i s , the functional n a t u r e of the ?ode
(which we have more appropriately designated as t h e "pragmatics" of programming slull). Such r e s u l t s a r e encouraging insofar as they suggest the utility of s u c h a memory task as one measure for assess- ing computer programming skill development. More research will be required, however, for t h e performance levels of individuals r a t h e r than groups to be i n f e r r e d from their performance on program memory t a s k s .
It is also a widely replicated finding that expert programmers debug their programs in different ways than do novices (Atwood & Ramsey,
1978; Gould, 1975; Gould & Drongowski, 1974; Youngs, 1974).
Perhaps most important is the recent finding (Jeffries, 1982) that program debugging involves comprehension processes analogous to those for reading ordinary language prose. Experts read programs for flow of control (execution), r a t h e r than Line by line ( a s t e x t ) . In terms of identifying t h e specific cognitive activities involved in programming ( t h e necessity of which we argued for earlier in o u r discussion of t h e cognitive demands of computer programming)
,
we need a more comprehensive account of the task of programming.Recent research in cognitive science provides such accounts, and to these theories we now t u r n .
Theories of Cognitive Subtasks Involved in Programming
It is the consensus of cognitive psychologists who have developed global theories of e x p e r t programming skill t h a t computer programming is highly complex since "it involves subtasks that draw on different knowledge domains a n d a variety of cognitive p r o c e s s e s " ( P e n n i n g t o n , 1982, p. 11). J u s t as in t h e case of theories of problem solving in general, cognitive theories that have been developed of expert p r o - . gramming articulate a s e t of distinctive cognitive activities that take place in the development of a computer program. These activities a r e required for programming whether the programmer is novice or ex- p e r t , since they constit& phases of the problem-solving process in any general theory of problem solving ( e . g , , Heller & Greeno, 1979;
Newell & Simon, 1972; Polya, 1957). They may be summarized as:
(1) understanding t h e programming problem; ( 2 ) designing or plan- ning a programming solution; ( 3 ) writing a programming code that implements t h e plan; and ( 4 ) comprehension of t h e written program and program debugging. We will discuss each of these cognitive subtasks in t u r n , with an eye toward thinking about what kinds of cognitive demands each of them may make on the programmer.
1. Understanding t h e Problem
It is generally agreed that in attempting to solve a problem, the problem solver f i r s t sets up some form of "problem representation" in working memory which is used to model a problem in terms of what the problem solver knows about the problem domain, and how that knowledge is organized for h i m or her. En recent studies (e. g . , Chi, e t al., 1981). substantive qualitative as well as quantitative differ- ences in the problem-solving processes of e x p e r t s and novices f o r a given content domain, such as physics, have indicated that experts
s e t up radically different kinds of problem representations in their early attempts to u n d e r s t a n d t h e problem p r e s e n t e d . In the case of applying physics to mechanical problems, e x p e r t s engage in extensive qualitative problem analysis, o r processes of problem u n d e r s t a n d i n g , before attempting to solve t h e problem, for example, through setting up a physical representation of the problem situation that was initially depicted in words (Larkin, 1977; McDermott & Larlun, 1978; Simon &
Simon, 1978). Physics e x p e r t s focus on deep s t r u c t u r a l features of the problems in problem categorization s t u d i e s , sorting together problems which would b e solved according to specific laws of physics, unlike novices, who focus more on t h e s u r f a c e s t r u c t u r a l features of the problem s t r u c t u r e , s u c h as the objects involved, physics terms used, and the physical configurations described in the problem (Chi et a l . , 1981). What t h e e x p e r t appears to know is what kinds of features of the problem should constitute p a r t of their problem r e p r e - sentation; this knowledge i s apparently f a a l i t a t e d by large-scale memory units in terms of problem t y p e s t h a t are identified in terms of deep s t r u c t u r e , a n d b y t h e e x p e r t s ' facility in rapidly building qualitative physical symbolic representations of the verbal problem statements.
h a discussion of a computer-implemented model of physics problem solving, Larkin (1980) notes t h a t t h e importance of a deep problem representation d u r i n g t h e problem understanding process is that
using t h e s e qualitative f e a t u r e s , the [computer simulated]
solver tentatively selects a method for solving the problem.
It then applies key physics principles from that method to generate qualitative information about t h e problem--for example, information about t h e direction an object moves
[ o u r Design and Planning cognitive s u b t a s k ] . When suffi- cient information has been generated to solve t h e abstracted qualitative problem, t h e model solver elaborates this quali- tative solution b y generating corresponding quantitative equations [ o u r Program Coding p h a s e ] to actually solve t h e original problem. ( p . 116)
What is illuminating f o r thinking about computer programming from problem-solving s t u d i e s s u c h as t h e s e , and in o t h e r domains s u c h a s geometry (Greeno, 1976) o r writing (Flower & Hayes, 1979), is that the problem solver must have substantial domain-specific knowledge in order to s e t up a functional problem representation. With respect to understanding t h e problem, Larkin's physics solver "had to know what h n d of f e a t u r e s to a b s t r a c t in constructing a useful simplified problem. I' For developing a problem-solving p l a n , it "had to know what h n d of operations he could apply to solve a b s t r a c t e d problems,"
and for working out t h e details of the problem solution had to know
"ow these [operations] were to be elaborated when he r e t u r n e d to construct a full solution." Although solution debugging is not men- tioned in this work, presumably he would also have to know how to check whether o r not the solution was a correct one.
So domain-specific knowledge is v e r y important for understanding the programming problem. Lf a child was asked to write a graphics program to draw a Colonial home, s h e would have to know about what Colonial houses looked like, their key identificational features, and so on. Similarly, to develop a game system, a c h l d would need to know the many domain-specific facts about computer games, such as vari- able skill level, score feedback, and so on. Since domain-specific knowledge is s u c h a fundamental aspect of understanding programming problems, serious thought needs to be given to what we know about conceptual development for any given content domain for whlch we a r e interested in posing programming problems for children. Certain domains, such a s statistics, o r simulations for complex domains such as ecosystems and economics, may well be out of reach for school- aged children, and constitute inappropriate programming project content. But t h e g r e a t variety of domains t h a t children are learning about in school should provide ample opportunity for rich pro- gramming projects.
A s for the specifics of t h e categories or types of prablems that the expert programmer i s able to identify in attempting to understand t h e , programming problem, many different alternatives have been s u g g e s t e d , and little empirical evidence, even for adult e x p e r t s , exists to dis- tinguish them. We summarize those described by Pennington (1982) below :
a ) Function-oriented. Problems would be seen as indicating different program goals o r functions, in terms of what is to be ac- complished, s u c h a s "update inventory accounts and produce r e p o r t s "
(e. g
.
, Balzer,
Goldman & Wile, 1977; Shneiderman & Mayer,
1979).b ) Data1 process-oriented. Problems would be seen as specifying external object classes (e. g
. ,
updates, inventory accounts, s t a t u s r e p o r t ) , and operations (e. g. , transform initial objects to final ones) applied to specific classes of objects (e. g.
, Brooks, 1982 ; Miller grGoldstein, 1977)
.
e l Sequence-oriented. Problems would be decomposed into their basic components o r procedures, and problem representations would contain sequencing information (e. g
.
, Atwood, Jeffries & Polson, 1980).
A s noted above, the problem representation t h a t s e r v e s as the out- come of the problem-understanding process i s one of the most funda- mental components of t h e problem-solving p r o c e s s , for programming a s well as other content domains. For t h i s r e a s o n , we expect the cogni- tive subtask of u n d e r s t a n d i n g t h e programming problem to be devel- opmentally central. The cognitive demands of understanding pro- gramming problems, a s we have s e e n , will depend at least upon the extent and organization of a child's domain-specific knowledge that i s required for the problem a t hand. But since t h e adult expert pro- grammer literature i s c u r r e n t l y equivocal on what forms such problem representations may t a k e , we cannot make precise the cognitive demands of program u n d e r s t a n d i n g . For a t least some of the pro- posed alternatives, datalprocess-oriented and sequence-oriented , t h e child would need to b e able to learn about t h e different classes of data objects and operations, in t h e first c a s e , a n d about the concepts of "procedures"and "sequentiality, in t h e second case. Such basic requirements have d i r e c t implications for defining a "core" of minimal programming knowledge, to b e discussed below.
2. Designing I Planning t h e Program
After achieving an initial problem r e p r e s e n t a t i o n , the programmer needs to map out a plan o r design for t h e program to be written later in programming code. Atwood e t al. (1980) provide an informative description of t h e requirements of this process :
Software design i s t h e process of translating a s e t of task requirements (functional specifications) into a s t r u c t u r e d description [ d e s i g n o r p l a n ] of a computer system that w i l l perform the task. T h e r e a r e t h r e e major aspects to this description. T h e original speafications a r e decomposed into a collection of modules, o r s u b s t r u c t u r e s , each of which satisfies p a r t of t h e original problem description. This is often r e f e r r e d to a s modular decomposition of the problem.
In addition, t h e s e modules must communicate in some way.
The designer must specify the interrelationships and inter- actions among. t h e modules [also called p r o c e d u r e s in smaller systems
1 .
This includes the control s t r u c t u r e , which indicates which modules a r e used by a given superordinate module to do i t s work and the conditions u n d e r which they a r e used. Lastly, a design may include a definition of the data s t r u c t u r e s r e q u i r e d . ( p . 3 )According to Brooks ( 1 9 8 2 ) , one-third of t h e e n t i r e time a program team spends on a software project (including coding and testing) should be s p e n t planning the task. Atwood e t al. (1980). in a de-
tailed analysis of t h e think-aloud protocols of two expert software designers a s they solved a software design problem, found that they - had available many general design strategies, s u c h a s problem decom- position, subgoal generation, retrieval of known solutions, generation and principled o r npolicy driven"se1ection of alternative solutions, and evaluative analysis a n d debugging of solution components. It i s of some importance i n this respect that a major move in programming instruction is to t r e a t programming as an instance of a general prob- lem of s t r u c t u r e d design (Floyd, 1979) , r a t h e r than as machine and programming language-specific (Sheil, 1980 1.
At this point, someone is bound to object t h a t , in t h e programming process, i t i s possible to bypass this s t e p of program development altogether, t h a t one may f i r s t make an initial reading of the problem, then sit down a t t h e keyboard and begin composing code to achieve the task. And i t has been said (Galanter, 1983) that one frequently finds much preplanning in PASCAL (a compiler language) program- ming, but often little o r no planning prior to code writing for pro- gramming languages such a s BASIC (an interpreted language). What are we to make of this observation in terms of defining design and planning as a distinct cognitive subtask in programming? Is i t op- tional? The answer to this question certainly has consequences for the cognitive demands of p r ~ g r a m m i n g , if one subtask ingredient to it.
involves whatever cognitive prerequisites there a r e for planning and design.
In response to this objection, we allow for the distinction commonly made, and applicable to t h e cognitive activity of programming, be- tween planning-in-action v e r s u s preplanning (Rogoff & Gardner , 1983). In terms of this distinction, what the BASIC programmer i s engaged in a s he o r s h e sits down and begins to generate program- ming code without a prior plan is planning-in-action, making decisions a s he or s h e goes about t h e s t r u c t u r e sf the program, which evolves as the materials of the program are created. Schon and Bamberger (1982) have described t h e outcomes of such a planning-in-action creative process in art, music, and other related domains as a conse- quence of an iterative series of '~conversations" th e creator has with his or her partial creations. Bereiter (1979) has characterized a similar process in composing language text a s "epistemic," in w h c h one comes to see and understand new things a s one channels one's ideas into a written product. But to r e t u r n to programming, d- though planning-in-action is certainly possible, even sufficient, to produce a program, we expect such a planned-in-action program often to have great costs for t h e beginning programmer. The reason has to do with the anticipated difficulties of comprehension and debugging when one goes back to t r y to understand what one has done in
writing a program not built with foresight. Of c o u r s e , for e x p e r t programmers t h e s h e e r automaticity of many programming projects, since they a r e able to recall successful plans f o r similar programs o r software systems, will mean t h a t little preplanning will be r e q u i r e d for the program code generation. In other words, the adult program- m e r often can integrate the s u b t a s k s of planning and code writing.
But the child as novice programmer i s not a t that level of u n d e r - standing, and does not have a s t o r e of programming schemas available for ready reference d u r i n g planning-in-action while creating a pro- gram. So we WLU continue in o u r discussion of the cognitive demands of programming to include t h e cognitive demands of the planning1 design cognitive s u b t a s k of programming.
In terms of cognitive demands, details of the various proposals f o r how planning takes place in programming, whether the top-down orientations with successive plan refinement o r more opportunistic approaches analogous to t h e work of Hayes-Roth and Hayes-Roth
(1979) , imply t h a t preadolescents may have difficulties generating program designs, particularly ones t h a t a r e complex and r e q u i r e hypothetical and counterfactual reasoning more characteristic of the older child. We shall provide a brief review of this l i t e r a t u r e in t h e section on conceptual development and programming. One of the principal cognitive problems comes down to what Stefik ( l 9 8 l a , 1981b) in his artificial intelligence work on planning called the recognition of
"commitments" of plan components, involving seeing ahead or symboli- cally executing plans o r plan p a r t s in o r d e r to mentally simulate t h e consequences of p a r t i c u l a r design proposals, and finding problems with those commitments t h a t indicate t h e need f o r a new design.
Pennington (1982) h a s indicated problems with the v e r y g e n e r a l n a t u r e of proposals t h a t program plans a r e hierarchical in n a t u r e , such hierarchy r e p r e s e n t i n g successive refinements of the program description until a solution t h a t can be mapped out in programming code is reached. How do each of t h e s e successive versions of t h e plan represent a n d f u r t h e r elaborate t h e f o u r basic types of program information, t h a t is: ( a ) t h e purposelfunction of a particular plan unit; ( b ) the s t r u c t u r e of t h e data objects; ( c ) the sequencing of operations (control flow); a n d ( d ) t h e transformations of data objects
(data flow)? A s s h e notes:
Little empirical evidence exists on how programmers coordi- nate and transform t h e four t y p e s of information embodied in a final programming p r o d u c t , yet i t seems that these coordinations underlie the complexity of programming and other planning t a s k s . ( p . 19)
We would agree here, b u t note further that studies of the develop- ment of planning for any content domain are in their infancy (Friedman, Scholnick & Cocking, 1983; Pea, 1982). What evidence exists indicates t h a t , at least for planning problems utilizing familiar classroom chores in a chore-scheduling task where the goal is to find the shortest possible plan for doing all the chores, children from 8 to 1 2 years of age are capable of substantial "debugging" of long plans through revisions.
We may now ask: What programming knowledge is necessary to design the program plan? A s discussed earlier, expert programmers chunk familiar patterns of programs, as indicated by the quality of their program comprehension as indexed by program recall. It is currently unclear how this knowledge is organized or acquired (an account of cognitive skill acquisition comparable to J. R . Anderson
[I9821 could be offered as a model of the l a t t e r ) , although these are fundamental developmental questions.
Some proposals have been made on the character of the expert pro- grammer's memory store, but little evidence is available. Some alter- natives as reviewed by Pennington (1982) -are set out below, and aim to answer the question of what programming knowledge schemas o r chunks are available to the expert. The implication for our questions about children are that whatever kinds of programming knowledge are required by children of the age of interest would have to be learnable in order for program plans drawing on such knowledge to be achev- able. So what are the schemas?
a ) Anything from transactions (less than a programming state- ment) to chunks (unit that accomplishes a goal) to higher level chunks (familiar algorithms) (Mayer, 1981) ;
b ) Hierarchy of patterns from operations (compare two numbers) to small algorithms (sum an a r r a y ) to large algorithms (bubble s o r t ) to program patterns (Shneiderman 1980; Shneiderman & Mayer 1979);
c ) Known solutions /plans /plan elements ( Atwood, Jeffries &
Polson, 1980; Balzer et al., 1977; Miller & Goldstein, 1979) ;
c l ) High-level programming units such as loop and recursion strusture (Rich, 1981; Rich & Shrobe, 1979; Soioway & Woolf, 1 9 8 0 ; Soloway et id., 1 9 8 2 ) ;
e ) BuiJding block units such a s basic loop, augmentation, and tilter (Waters, 1979) ;
f ) Categories with internal s t r u c t u r e , s u c h as r u l e s for data s t r u c t u r e s , enumerations (looping c o n s t r u c t s )
,
mappings, etc.(Barstow, 1977, 1979).
3. Coding a Program
This phase of program development consists of a translation from the most refined version of t h e program design into the programming code. Brookst (1975) estimate of less t h a n 200 coding templates necessary to define t h e syntactical arrangements of code in statements makes clear why i t i s said in the programming i n d u s t r y that coding is a much simpler process than program d e s i g n , which appears to in- volve a much more v a s t and initially ill-defined problem space.
According to Brooks (1982), only one-sixth of t h e time allocated to a software project should invlove the actual writing of the program code. It is unlikely t h a t this phase can b e completely independent of the program planning phase
,
since different programming languages provide different options for plan implementation, s u c h as " t h e availa- bility ( o r lack) of linked list data structures"(Pennington, 1982, p . 2 4 ) .Brookst (1975, 1977) s t u d y of a programmer's coding performance found symbolic execution, o r what we might describe as mental simu- lation, to be t h e major f e a t u r e of t h e coding process. Brooks' account postulates t h a t
a plan element t r i g g e r s a series of s t e p s through w h c h a piece of code is g e n e r a t e d and then t h e programmer "sym- bolically executesn t h a t piece of code in o r d e r to assign an effect to i t . This effect i s compared with t h e intended effect of the plan element; any discrepancy causes more code to be generated until the intended effect i s achieved.
Then the next plan element is r e t r i e v e d a n d the process continues. Throughout this process a representation of the program is built u p , storing information about the objects (variables, data s t r u c t u r e s , etc. )
,
t h e i r meanings, and their properties. (See Pennington, 1982, p.
2 4 )Once again, as in t h e case of plan construction where symbolic exe- cution plays a major role, we find t h a t program coding requires s u b - stantial hypothetical thought. A s for the cognitive demands of gen- erating program code, we may note t h r e e general classes of apparent prerequisites: ( 1 ) ability to engage in hypothetical symbolic exe- cution of code; ( 2 ) ability to learn t h e coding templates that define the syntactical knowledge necessary for code generation : and ( 3 ) ability to keep to the goal at h a n d , o r program plan, unless deviations from it a r e r e q u i r e d to generate the code; in such a n
event the plan would need to b e revised, with consequences for the code then to be generated to achieve it.
4. Comprehending a n d Debugging a Program
How do programmers comprehend programs? In o r d e r to debug o r modify their programs, they need to learn from their own o r o t h e r s ' programs. If they a r e to realize how much p r o g r e s s they have made in developing a program, comprehension must play a key role. One extremely useful paper in thinking about this problem is b y Green, Sime and Fitter (1980), who emphasize at some length the importance but current neglect sf developing means for "getting information
-
out of programs as well a s into themL-the program comprehension prob- lem. They note that "some of the major problems [ a programmer faces] come when the program is being debugged, o r extended, o r modified, or just when t h e p a s t half-hour's work is being reviewed"( p . 8 9 4 ) . Pennington (1982, p. 29) notes that "program comprehen- sion also involves reversing the forward mappings from problem representation in t h e external domain to successive levels of plans to programming language code." Program comprehension would t h u s require a n inferential retrieval of the program creation process.
Four very different views of t h e program comprehension process have been proposed, and they have not been compared in terms of their empirical validity: one is bottom-up, one is middle-out, one is top- down, and one is transformational (Pennington, 1982, pp. 26-27, whom we follow closely in this section). Shneiderman (1976) finds expert programmers to recall more g i s t , o r high level ldgic, of the program than do novices. He later (198Q) argued for a bottom-up construction of meaningful units of programming code, from operations to aigsrithrns on up to the £unction of the program as a whole.
Atwood and Ramsey (1978) have a multiple pass model analogous to- Hayes-Roth and Hayes-Roth's (1979) opportunistic model of planning, in the sense t h a t programmers utilize high-level and low-level infor- mation about t h e program s t r u c t u r e advantageously in o r d e r to under- stand the program.
On the first p a s s , some level of the [program] macrostruc- ture is i n t e g r a t e d , possibly as high as program function, possibly at some level of chunking. Successive passes lead to integration of lower level propositions (working down) and successive integrations of the macrostructure (working up). (Pennington, 1 9 8 2 , p . 27)
Brooks ( 1 9 8 2 ) views program comprehension as hypothesis driven and a s immediately seeking out the high-level schema for the program.
The program reader then is said to seek out evidence for predicted program components consistent with their high-level expectations.
This process works iteratively until the program reader has assimi- lated all the code to understand i t s precise workings. The complex transformational account offered b y Rich, Shrobe and Waters (Rich, 1981; Rich & Shrobe, 1978, 1979; Rich, Shrobe, Waters, Sussman &
Hewitt, 1978; Rich & Waters, 1981; Shrobe, 1979; Waters, 1978, 1979) implies that program understanding is mediated b y a hierarchical representation of t h r e e levels: (1) deep plans (purpose) ; ( 2 ) surface plans (in program s t r u c t u r e ) ; and (3) definitions of data objects, properties, and 110 specifications for program code segments.
What does all of this mean for the child who needs to be able to comprehend programs as one cognitive s u b t a s k of programming?
Again, this is a complex question, since even a t this level of subtask analysis this question is analogous to t h a t of "What are the cognitive demands of (natural language) t e x t comprehension?" which is f a r too general a question to be meaningful psychologically. The question asked should instead depend upon what kinds of text (in terms of text g e n r e ) , logical complexity of t h e t e x t , in terms of the inferences required to understand i t (e. g . , Clark, 1977), constituent state- ments, words and, in the case of t h e beginning r e a d e r , even l e t t e r s , of which the text is composed (e. g., Gibson & Levin, 1975). At the most basic level, children would have to b e able to read the lines of code and identify the meanings of the constituent elements of the program, or primitive commands. This much is basic. But a much more complex task is to understand t h e i n t e r r e l a t i o n s h p s between these lines of code, to recognize the units, modules, or procedures which make up the meaning of the program as a whole. Studies (e. g . , Kurland & Pea, 1983) demonstrate t h a t comprehending pro- grams a t multiple levels is a difficult task even for relatively expe- rienced child programmers from 8 to 12 y e a r s of age. However, what is a s yet unclear is whether children do not tend to comprehend programs at "deepn levels because they have difficulty decoding even the surface s y n t a x , o r whether for the type of programming activities children typically engage in t h e r e is little incentive to probe below the surface.
We have provided a brief account above of the four major constituent cognitive subtasks of programming insofar a s they are currently understood in the literatures of cognitive science and software psy- chology. What we have observed is that even a t this level of speci- ficity, although we can articulate at a general level some kmds of knowledge and abilities t h a t children should have in order to mentally
