.,,>, be charged a mini . each non-r.tu'«d °'J ^ ,«£*£- , lllinoi. and are pr .aw and Procedure. , 333-8400. TO RENEW CMXW a^prffl^ APR 25 W h e nr e^ gr ^r WrUeneWdUe ^ below previous due date. Digitized by the Internet Archive in 2013 http://archive.org/details/analyzinglearnin910kruc £1 & r ~ fLC ' tfiuCDCS-R-78-910 UILU-ENG 78 1701 Of ■ 2 ANALYZING THE LEARNING OF COMPUTER PROGRAMMING CONCEPTS THROUGH THE TEACHING OF PAL by January 1978 Hanna Kammerahl Kruczek 01978 DEPARTMENT OF COMPUTER SCIENCE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN • URBANA, ILLINOIS Report No. UIUCDCS-R-78-910 ANALYZING THE LEARNING OF COMPUTER PROGRAMMING CONCEPTS THROUGH THE TEACHING OF PAL by Hanna Kammerahl Kruczek January 1978 Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 *This work was submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science, 1978. CcJ Copyright by Hanna Kammerahl Kruczek 1978 3 /u&^ iii ACKNOWLEDGEMENTS I wish to thank dll individuals who have contributed to the preparation of this thesis. Special appreciation goes to my advisor. Professor Jurg Nievergeit for his inspiration, gui- dance and patience throughout the project. I would also like to thank the memners of my thesis committee tor their sugges- tions and direction, especially Professor George Friedman who contributed numerous helpful suggestions. Professor Ben Sch- neiderman and Dr. George Fisher also deserve thanks for their comments. I would further like to express my appreciation to Mr. John Angell of the Veterans Administration for his help in the preparation of the thesis. My thanks also go to the people who have assisted with the testing phase. John Clement deserves special thanks for his help with the children and Paul Wussow for providing a testing facility in the Chicago area. A special appreciation goes to Timmy and Linda as well as to Patrick, Jodi and Mike for the many hours they contributed as subjects. Finally, I would like to thank my husband, Jerry, whose assistance was invaluable. He advised, edited, proofread and generally supported my efforts throughout the project. IV TABLE OF CONTENTS Page ACKNOWLEDGMENTS iii 1 Introduction 1 1.1 Why Teach Children Computer Programming?- ..... 1 1.7 What is Involved in Learning to Program?, ..... 3 1.1 what has been Done in Introducing Programming?. . . 4 1.4 Why Another Programming Systrm? ..... 12 2 PAL and its Programming Concepts 16 2. 1 System Description. 16 2.2 Observations on Programming Concepts. ....... 31 2.3 How PAL Embodies the Programming Concepts ..... 34 2.4 Common Concepts not in PAL. 41 3 Experiments to Determine how Programming Concepts are Learned 43 3.1 Case Studies in Teaching PAL 43 3.2 Sample Protocols of Sessions. 45 3.3 Observations Derived from the Tests 77 3.4 Summary and Conclusions 10o 4 Concluding Thoughts Ill 4.1 H ecomraendations for Teaching PAL Ill 4.2 PAL is a Good Vehicle lor Teaching Programming- . . 111 4.3 Future Considerations . . . . . . 112 4.4 Conclusions 112 BIBLIOGRAPHY. . 114 APPENDIX A DEVELOPMENT AND DESIGN NOTES 117 APPENDIX B FORMAL DESCRIPTION OF PAL. 121 APPENDIX C A BRIEF DESCRIPTION OF THE SESSIONS WITH CHILDREN. . . . 122 APPENDIX D SAMPLE PAL PROGRAMS. 129 VITA ,. 13b 1 In t Toilet ion. 1.1 ; .,'hy Teach Children Computer Progr imming ? 1.1.1 Programming is in Important Concept to Know. Computers .ire becoming moie and mora necessary inl prominent in our society- our I) ills and checks ire produced fay computers. The smalLest companies use data processinq to keep their books. Everyone should Know how to deal vita computers, to realize that people, not computers, run the world. As T. Hay Nanney (17) points out, most major policies ami decisions regarding computers will be made by non- computer scientists. The need for teaching children the concepts of comput- er programming in elementary school was recognized by David Mousoud and Mike Neill (16): "One mission of the elementary school is to provide students with basic skills of information processing and problem solving." Decreased costs of technology make it more and more feasible to introduce computer scisace in elementary schools. 1. 1..' Programming reaches Problem Sol.vi.nl Techniques. In writing programs, childien must demonstrate the ibility to analyz e problems and plan solutions. They must h'.»t proposed solutions, study the results and, if necessary, revise the solutions. The; above are very necessary general problem solvinj techniques that can be introduce! to children in a simple, interesting way by filching thorn computer programming. This point was *mp]i*""ied bv Dean frown and tfo harmed A. fti-Ghannaai (b) : 'in writing their own programs, trie children learn to organize their tninking into an aljorithmic form. If they are young, t teacher work;> with their.. Designing and writing a new program is one o ; the most useful of ill peiagogical lev ice u because it stimulates the children to think of all possibilities that mignt. occur when other ch.il 1 r en e x e r c i :-> e t he p ro g r a m . " Papert (22) Lis made extensive use of computers to teich children problein-solviag techniques. His LO'50 system is used by adults as well as children for an easy iVi\i enjoyable introduction to writing programs for solv- in ] problems. 1.1. < Programming ')ff ;rs Stimulating Open- End e J Activities f )l Chi J d ron. l Introduction. 1.1 ; .ihy Teach Children Computer Proyr imraing ? 1.1.1 Programming is in Important Concept to Know- Computers .ire becoming mote and mora necessary anl prominent in our society- C)uc bills and checks a re produced by computers. rha smallest companies use data processing to keep their books. Everyone should know how to deal vita computers, to realize that people, not computers, run the world. As T. Hay Natality (17) paints out, most major policies and decisions regarding computers will be wade by non- computer scientists. The need for teaching children the concepts of comput- er programming in elementary school was recognized by David Mousoud and Mike Neill (16) : "One mission of the elementary school is to provide students with basic skills of information processing and problem solving." Decreased costs of technology make it mOre and more feasible to introduce computer science in elementary schools. 1. 1.;' Programming Teaches Problem Soivinl Techniques. In writ in j pragranis, children must demonstrate the i i i 1 i t y to analyze problems and plan solutions. They iflust test proposed solutions, study tha results and, if n ooessary, revise the solutions. The above are very necessary general problem solving techniques that can be introduce] to children in d simple, interesting way by teaching them computer programming. This point was amplified by Dean frown and ft oh am mod A. El-Ghannaa (6): ''in writing their own programs, the children learn to organize their thinking into an aljorithmic form. If they arc young, a teacher woLk:. with them. Designing an i ■rrit.inq a new program is one o ' the most useful of ail pedagogical devices because it stimulates the children to think of a LI possibilities that might occur when other children exercise the program." Papert (22) 1. is made extensive use of computers t^ teach children broblem-so'lvi ig techniques. His I.O'JO system is used by adults as well as children for an c^asy and enjoyable introduction to writing programs for solv- ing problems. 1.1. < Programming iffars Stimulating Open-£n.ieJ Activities r >l ChiJdren. processes". P. J. Barker (2) also stated that wo should think carefully about the first prog rammi ng language taught to children. "There is a strong indication here that readability and accuracy are connected probably because most of us tend to verbalize our ideas when trying to solve problems," 1.3.1.2 Programming in "Natural English". Programming concepts were introduced in "natural English" by Killer and Becker ( 1 r >) . Tne students taught to program in "English;" ased virtually n :> tranter of control. Sinse "natural" languages are basically linear,' programs written in "English" used mostly linear sequencing, as one would ir "telling 1 story". Programs written in English also were not well olanned, the narratives were insufficient. in "natural linguage" conversations mucn knowledge is taken for granted and every step does not have to Pe carefully detailed. This tendency seamed to carry over to programming when "English" was used, but in programming nothing may be assumed. 1.3.1.3 Languages Developed for General Information Processing. Southern Illinois University at Carbondale did 1 study to investigate several existing general purpose languages for tlu-ir suitability for pelajogical usvi (?7)» They use i tho following ccit'?rii tor eating the Ian qua jes : 3. \va ilab ility of subset t.")c beginners b. Support oi upyar lev->L coucjos ('.J- data st rue tares) : . Suitability for teachinj about programming stylo (r^dldbl^ com, control structures) 1. Textbook availability o. Impact of .'. lepartment nin iconouter f. Erficiency md turnaround j. Language isoi in "real" world h , S e r v i C ! i "he study committee concluded that FOPTPAN has control structure tin Its which ire some wa at remedied by "STPUCTUUED FORTRAN", but th it would merely postpone the issue, LI.it' is too complicated for beginning students and BAS7C is too s i»i • 1 i ;>t ic a Language. COBOL doesn't have a good simple subset and it is expensive. Therefore they decided that PORT3AN, LISP, BASIC and COBOL were definitely unsuitable. There was little lemand for ALGOL W, EIJI.ER, SnOlOL or PASCAL outside the department- If this were not a factor, they concluded that PASCAL woull be the choici for a language to use in the introductory courses. At that point the lan- guages left were PL/1 anil Assembler. PL/1 was chosen as a primacy high level language and Assembler will still be taught to give the students an understanding of computer structures. I.3.1.4 Languages Specifically Developed for Teaching. Several languages have bean specifically developed for teaching. Soifle are variations of existing languages: a. rFTHA.N" = Structure! Fortran (Fortran with IF_- THF.N_ELScl Structure) developed at General Research corporation (S) , Santa Bdrbara, California. b. NSFTPAN = Nicely Structured Fortran (Fortran with inore» control structures) levelopei by Temple University (B) . c. LINTIS = Language for IN struct ion a 1 'JSe (similar to Algol 63) developed at Bowling Green State University (31). d. PBASTC (Basic with block structures) designed for a Brazilian aini -comput eL (?S) . "Artificial Languages" have been developed specifi- cally for teaching. Included in this group are: a. SIHPL-X a structured Language developed at the University or Maryland (4). b. HASY - Easy Assembler .jYstem developed it the University of Iowa (they also developed FeachEa'*Y v a cat system for teachiny -SASY (?fi))» 1. }.K r > Using a " Sequence of Languages". An ipproach thdT has not l-een ex t>» nsivel y triei was proposed by Leigard (1^). lis idea is to teach progr a.umin j i fn a sequence ox ten iiirii- la n judges, each designed to toach a particular computer science con* copt. This w.i/ each la ng u-i g>.' would he simple and e At'.y to lwarn and the progra mmi. ng concepts would bo i so la tod. A sequence of six subset s of i>L/1 (called SP/1 through SP/6) were developed at the University or Toronto (9,1'^). 2ach subset wis desi jned to teach a specific concept of PL/1. The system of languages is being marketed and has been use! heavily at the University of Toronto since I974. 1. x ..'.i Teaching Programming via CM. Several Universities have l^veloped CAI systems to toach compute*, science. Among them are the following: a. PLATO is an extensive CM project developed at the University or Illinois at "rleiu (1). .'art of c>LATO is a lar'jo subsystem for teaching compiter science (19). h . Computer-Tutor, a CAI system for teaching cornputec programming, was developed at the University of South Carolina (13). It contains a hint system, subtasks for expanding on a topic and an interactive graphic debugging i id *itn a trac-> option. Tt was founi that: "A common difficulty among beginning students in an inadequate or inaccurate u nderstandin j of program execution. In most systems, variaoie assign- ment, logical iecisions arri program branching aro all invisible to the user, and there is no way for the student to see the flow of execution of her program." 1.i.} Programming Systems Used to reach Children. 1.3.3.1 LOGO. The LOGO system was developed at MIT. It is the most. extensive project aimed at. teaching computer programming to elementary school aged children. Tn developing LOGO Seymour Pupert (22) had "a grander vision of an educational system in which technology is used not in the form of machines for processing children but as something the child himself will learn to manipulate, to extend, to apply to projects, thereby gaining a greater and more articulate mastery of the world, a s«nse of the power of applied knowledge and a sel f -confidently realistic image of himself as an 10 intellectual agent," The goal of LOGO is to "amplify the correct ways of thinking" by teaching the children to (20): a. Look for a cecuusive model. b. Break a problem into sub problems. c. Look tor simple and extreme rases. i. DiscoveL and investigate bugs." LOno is used mainly by firth graders to make interesting things happen, including drawing pictures, making music, and moving mechanical "turtles". T'n^ children Learn by causing things to happen (?J). I'hey are encouraged t ■> experiment, not to view errors as personal failures. Progr a ■i.mi n q "bugs" are not their fault; "the computer goofed" (2 1). Randy Stern (29), commenting on ficst grade LO'»3 experiments conducted by Cynthia Solomon, posited that first grade children "seemed to have ga t »s in their number lines", that they had i i£t iculties using numbers greater than 10. The children also 2X pec ted the command "i>^" to move the turtle to the right (instead of just rotating it). For teaching LOJO to first graders, he recommended simplifying it to a level easily understood by young children. Pa^ia Perl man developed TOiiTIS (2 4) (ToHLer's Own 1 1 Recursive Turtle I n terpreti. ve System) it MIT- With TORTIS, buttons on one box represent entire tur^l^ commands while buttoiis on inotb.or box 'ire editing commands, a chill starts with few buttons and more -i c-; added .is he gains pxpprience, 1.3.3.2 SMALLTALK, SMALLTALK (11) was developed at the iZP }< Palo Alto Research Center and is used in conjunction with "DYNA- 300K" to create picture books- The Language is similar to LOGO- nne difference is that the commands are symbols instead of words and ara accessed via i keyboard (e.g. pressing a particular ke/ would produce a command symbol). As with LQ10, "turtles" and music boxes can also be connected to the system, SMALLTALK is primarily used by junior high and high school students. 1.3-3,3 SOLO. The S0LOW0RKS Computer Labs (28,7) are located at the University of Pittsburg* Their goals are similar to those or the LOGO project in that they want to teach children how to make the computer do interesting things. Junior high and high school students use BASIC to simulate lunar landings, write cjames -i nd teaching programs and work with graphic displays. u 1.1, 3.4 Other Projects Designed to Teach Prog r dm min-j Concept s. A course called "Inf. or mat ion" wi.; tau.jht to 12 to 14 year olds in British high schools (14)- The children studied information as an ossential part of organize! human activity. They learned about the information needs ot society, as well as the collection, anilysis, storage and retrieval of informat ion, 1 . '4 J it y Another Progr amminq. System? 1.4.1 Special Languages for Youny Children are deeded. In order to study how children learn programming concepts, a linguige is needed that children can issimi- late easily and in which pr ogr. a muling concepts are clearly distinguished, rhe Language should be specially designel to offer projrinminj to children it tha earliest possible age. This means that the language should not have reading, writing, number or keyboard skills -is prerequi- sites. The representation of the programming concepts should be as siinpl* as possible: a. The number or commands should be limited, b. The commands should be symbolic, their function easily recognised-, an i c. The language should hive few syntactical const ra in t s. n It should be possible to do interesting things (inter- esting and relevant to crhildren, such as animation) with a minimum exposure to the language. A sequence of mini -languages seems to be an appropri- ate strategy for teaching children programming. The first, language in such a series should bo chosen ror its pedagogical suitability. Each langua je could have a restricted environment to make the learning of program- ming as easy and naturally progressive as possible. 1.4.? PAL is a Unique Computer Language, 1 .4-2.1 PAL is Specially Designed for ifounger Audiences. All commands in PAL are symbolic pictures which, to be invoked, need only be touched. Reading, writing, number or keyboard sIciiLs are not needed to program in PAL. (Error messages are presently written on the screen, but they could be read by a teacher or transformed into Audio Responses, available on PLATO.) The commands of PAL have few syntactical constraints; practically all combinations of commands produce some perceivable results which can be "debugged". PAL offers a very restrictive environment which makes it ideal as the tirst in a sequence of mini -languages, with perhaps LOGO as the second. 14 1*4.2.2 PAL is a Progr amming System. PAL simulates a computer on the screen, displaying t he memory, workspace, available programming and edit- in j commands, current program, program pointer an 1 failure flag to jive a total picture of what id happening in -1 computer- The program execution is indicated with a hand (program pointer) pointing to tne command that is currently being executed. (Barr an 1 joarl (.3) indicated that the sequence of program •xecution i ; difficult for students to visualize. J 1.4.2.3 PAL has in Immediate Execution Moie. It is easy tor the children to gain tar. i liar it y with commands by usinj them in in 'im.nedia t'"» exectuion' molt 1 . They can go back to "immediately executing" commands while writing a pro jam to remind themselves o f how to caus° something to happen. 1.4. 2. a PAL rises the PLAT a Systvu. ?AI. is implemented on PLATO permitting PAL to incorporate soiu j of the uni-,u a PLA^O features, includ- ing ing the "touch panel" aiu special characters. As i future consideration, PAL cou Id make us** ol th j * PLATO audio system. Finally, sir.ee extensive elementary reading m^! math programs i.-ave been implemented on PLATO, PAL will be available in several elementary is schools. 1.U.2.5 Interesting Things are Possible with PAL. With PAL it is possible to draw animated cartoons, draw mazes and escape from them, write messages, etc. (See Appendix :j for examples of PAL programs.) Later it may be possible ror the children to get printouts of the displays which tney have created, which they cd\\ take home is cartoon books. 16 } PAL \ n .1 its P rogrammin \ Concepts. ..!. 1 System Description. /•. 1 . 1 Overview. Tii this a nd ill subsequent sections, ?*VL commands and program name? will ho enclosed in single quotes (')• )ne square in the '[lay irea' (see section 2.1.2) is always the 'active squire 1 (this is the current aidress). The 1 active square 1 cav be moved simply by touching the lesired new location. Touching \ picture in the 'store' (road only memory) causes the picture to appear in the ' finger box' (register used to keep trie: of tno last picture touched). The language commands the i operate on thf-> 'active square' and, i: applicable, ilso on the contents of the 'finger box'. For example, the command •join' super imposes the content oi the 'finger box' on t. hit in the 'active square', while 'move' moves the 'active square' ilorrj with its content! one position in th^ direction or the 'move 1 arrow. 17 2.1.2 System Components and Screen Layout run im! l_li v i ,':. : .^'./<^ > £ .f * ^^ 1*; Toy S t o r / $ 5 \ JfelSi ^ ■^B 4 fit * *" f n 6 D out , hanna dnvSrte J run str L I f 8 » J H S3 \L V >arr iaz€ I ECTTON CHILD' S NAME A Play Mrea B Store c Program Space D Commands i I'M i ting Commands p Finger 3ox G Prog cam Store H Active jjQdLe I Frown (to in d i ca t e a command had failed) PROGRAMMING CONCEPT Work S pace (read/ writ-.' memory) Re id fnly Memory Work Space Languige Commands System Commands Register Head/Write Memory Current Address Failure Flag 18 !. 1,1 Immediate Sxeoution 'lode. Commands aro executed is they "ii~<> t >uched. For jxample, the following sequence of J touches results in placing the witch on the screen (the picture was createi i- y Linda in session 5, see Appendix C): jSLi (rtj !aLL£i £ T. ^M 5 & d& yiA-A !>i V» T o y 5 t o r e ££&> # «51o> ^ 4 tf £ -00h » out hanna I 1 dr iv#rte strl Iflsf * >arr 1, Touching the witon in the 'store' causes her t> \ ■:. ; ' ea l in the ' f i n j e r b ox ' . 2. Touching bj i.i the • pla> aif'-a' moves the 'active square 1 to position oJ. 1. Touching 'drop' drops the witch Lnt> the 'activ s j ii a re ' - V? After touching 'move' (resulting in the four arrows expanding to tour single 'move' commands) ani three times th^ 'move rijfit' command, we get: -BU . L m ^ •£ T 5 4 A \/\ ^ 5> _ * J I H G F E D C B A T fill /ft/ft 6 ♦- iii Toy (m St o r e «@& 4 -»(D«- ►00-» ~0> -» n out Q Y anna w| /\r *j] * dr ivflrte /$ s\ Ltrt $ ifeS) If 1 sf J5» . ^ * oarr 4 I ^' s £_ ?.') Tho touch seouor.ce umbrella, ' join 1 , result ■; l n JaL &i gj y ■ 2 c T 5 ^ m \/i $ LJ j i H G F E D C B R HI /ft IV 6 -.CD* T o s^ ftg St o r e si&jg -»0D«- M00-. <0> -00h n out P hanna [W /\r drivjlrte /$ 5 \ Lrt 1 # ^(oi Iflsf -^ * parr 4 • "I'.-v * Tiazc fc£- s* abcdefghi J F1 P 5 te^ & 21 2. 1.<4 Program Writing Mode. ToilC el uses a i, Co n ra and i ppoa r ThO t y ;> i n j na pic. t 7 ;i{> a "pi a /in h l ii g IAL to .lot t el s tone in t he folio "run" (Typi S e q u e n g" wit the 'write' system command (writing hana) Invoke the 'writ'' mode which is inriicatel uox appearing iround the 'write' symbol. Led while the system is in the 'write 1 mode • [To ) ra in space ' . wing resulted tio.w touching 'write' and dS a reply to tie- request for a program nq skills are not needed, children need only ce or jne to lour letter;-,; they enjoy h the Keyboard.) M ELJ_L£1_£ T 5 -cl ^M ■rr f ■^^r^ & &x Toy St o r e $@g $3® $ .%£ A ^ 4 ou#r^ tf J T -00- ♦GD* AVv; ■00- n 6 out hanna I;] dr ivljrte abede fgh i j H R B 1 a 1 itH flsf * oarr •naze 2? Touching i h" sauto sequence or commands is in 2.1. 1 completes thv program: sec ti on r u n ' , fi :- Ait El V it** Ju V ;■*» 1 5 •^ i * \/ll J b J T /i, /i, 6 6 j i H G F E D C B R - -♦ CT 4- y-y, y^ y-\ .<*T.V». _j l o r e !s4a» i -00-* ^ -♦ -♦ n out -♦ hanna|| /\r * * dn v rte /$ 5\ L{ i # ife(?l flsf A ^ * oarr 4 <-C/y * •naze fc£ "J 1 abcde fgh i ] s. »> SI" J? f Fhe child can then store th« ^rograra by touchinj •wrap* whicli will place the ii-irca 'run 1 into the ' prcqram 23 2.'\. r > Program [execution, After the program is written, touching 'ran' (tlv* running boy at the bottom of the screen) causes the commands to be executed. The actions will be the same as 1 hoy were in the 'immediate execution' mode. (A {- -r- %fe» Toy im b t o r e ^ 4 -»GD«- hOO- 33? -» -♦ n out -♦ hanna|^ /\r *n * dr lvA-te /$ 5\ run *ktri # ifelli Iflsr A ^ * parr 4 * & 2 a b c d e f g h i J l> 6? 4 1 . 1 . (i Commands. "*. . I.b.l Language Commands. ?* Symbol ( + ouch ' st or •• ) (t ou ch ' plav .ifi'j 6 .t Description picture touched a;;jpars in the • r in jor box' ri.s i re m in lor of the lint 'store 1 picture touch oil. (The piet-uro is still symbolically on the ch ill' s fin -jer. ) •set ' uppea i:j5 touched , ■sq ua re s pace the a dot. ted • i roan l the This ♦ hen hoc ones is t. i v- iijinr '. 'drop' -- list 'store' picture touched (the one currently i:\ the 'finger b>x*) appears in the ' act iv * s m ir* 1 ' . (Fails it 'active square' occupied -- s^e the descrip- tion of 'lojp' lot the impli- cation of failure of comm t rid s. ) mov ■ > » square' posi tio! a no. l n moves ' ac^ivo its contents one the direct- ion indicate;! by the arrow, (FiiL; if 'active square* empty, destination occupied, or out sine the 'pi ay area'.) •move active' -- moves the •active square' (without con- tents) one position in direc- tion indicated. (Fails if hstiria* ion outside ' pi (i v a re.i • . ) 'eras 1 ' -- eraser- contents of •active square ' . 25 Symbol -♦GD*- «-00-» n out Q ijescri ption •join* -- .suporiifjoses picture in • finger box' over that in the 'active square'. 'take away' -- negates picture in 'finger box' from onn in 'active squire ' , dots that were the • i- mger dox i.e. tunu turned on in off in t h e 1 act iv e square* •loop' -- set of statements enclosed by 'begin loop' .ml '.en el loop' brackets. When program exacutioi: encounters 'end loop', control transfers to the matching 'begin loop'. 'out' — transfers control to the statement immediately fol- lowing the 'en 3 loop' if a command within the 'loop' had failed. 2*.1.b«2 5>ysten Commands 2b Symbol \ w •broom' -- erases ill of 'play ar ea' , Our S^ 1 it •do mod-.? 1 -- invokes 'immedi- ate execution' noie. 'write' -- invokes 'write' uio.lc. \ name for the program is l-' j uest.ej . 'wrap' -- store:., the program currenMv La the 'pro g r a ;a spac< • . •run' -- executes the pro. j rati in t. he 'program space'. 'zap' -- destroys f he program in the 'program space 1 and, if it In 1 been stored, its copy i ri th*» 'program store*- 2.1,7 f. xa in pies, 2.1.7,1 Bnv Gets RilLoons an! i ises with The .a. 27 cc, ' rf Al s 9 tt tf S ' 8 *%! * 4 v a B 6 6 J I H G F E D C B R r *-• > i -»0D«- -00-. 3& ■*(£>*- i n out Q r hanna(j|| t *n * dr i\«rte %y out run P 1 jflsf oarr * ■nazt a b c d e fgh l j v» 1> 1? J?. f The co m ma n<] 'out' will cause the 'program pointer* to exit the ' Loop' (thus ending the program) because the command 'move up' will fail when the top of the 'play area 1 is reached. 7A 2.1.7.2 Dcawiiuj i City. Program written by Linda in session fS (see Appendix nan* jL ^ 9 ; £ * £ T , -4 how * tre« a I : -P : 6 a A 6 j i H G F E D C B A lUFj 9 99 9?? 9999 -* cH Jt 6 -♦ \. abcde fgh i j n 6 *- : : -» n out 9 hanna i drivlrte run Istr ooylf 1 sf tre« \ houi Tiaz« IK oarr 1 in« 29 tl ««' ^^ Id V 1* V 26 ' 8 -nj a G vlrfe ^ tfffi* 1 6 j i H G F E D C B A That command fa 1 1 ec/ that will b« out ot the play are-00- 30> n out 9 hanna drivflrte run sti ^oy jflsf tre« how ™ Z€ ~i\ * 30 r i * _ai^ El V 4tfi ' i -*j af \/»i^ ** A 1 J I H G F E D C B fl V. • bF 1 in€ aE d iiii^fiffiii bE * 1 ine %y aO 6 i i » rte abcde fgh i j a n . 2 Enumeration of Concepts in PAL. 2. 2.2,1 System Modes. a. Immediate Execution. This mode is available with many interactive systems such as A PL and also with calculators. b. Program Writing. A program is a sequence of statements designed to 3? i >„ ~> . 7 2.2. 2. bo executed oy a processor. Editing . Procjra.ii Execution. Mode Chancjing.. 2.2 MemoLy aii'i Data. Da ta v ilnos . Data can take on values of "primitive constants" (e. g. ii'i.ut »rs) or "composite values" such ^s over- strikes of lines on printers or bac* spacing and o vcrstrik ing (a:j in TUTOE or APL). lata values also can only assune "discrete states". Variables. Variables are ".nemoty cells" or "registers" which roay have ro be "initialize!". Storage or Memory. Memory can be "read-only" or "re » 1 /write". To gain access r.o memory, ^n "address" roust be s peci f iel . 2.3 P rogra sis. 2.2.3.1 So. j ue 'tee of Instructions. The concepts associated with a program dS * sequence of instructions are: a. Static sequence; b. Dynamic sejuence; 3 \ c. Program pointer; 1. Syntax. 2.2.2.1.2 instructions. a. Primitive instructions include the "assignment statement" which assigns values to variables, the "unconditional transfer of control" (e.g. jump, goto), "conditional transfer of control", "opera- tions" (e.g. add, conipi re) , as well as addressing and referencing. h. Composite instructions include "procedures" which can be used as structuring mechanisms ol as exten- sions of t.n.> instruction set. Procedures can also be predefined such as square root functions in FORTH hV. . "Loops" (closed sequences of statements that will be repeated a finite number of times) are another type of composite instruction. Both "loops" and "procedures" can be. nested, resulting in new composite instructions. 2.2.2.3.3 Determining the Correctness of Programs. Progrims must r>e "debugged" and a determination made as to when the program produces the desired results. In tae process ot validating a program, a "desk check" of the program can be employed. 14 - 1 . 1 iiow PAL Embodies the Programming Concepts. >. i.1 The Overall Structure ot PAL. PAL simulates i computer in t h it it. presents the main parts of ; i computer an the PLATO screen- This simulation i ^ geared to children in that it ls entirely pictorial ml symbolic and is designed to jive children an under- standing of what a computer is. The com man is the child has available to aim are visible on the screen at alL times as a reminder of what he may use. Ti;^ access of those commands is very easy; a child need only touch a command to ev<».<« it . \ 1,2 Enumeration or Concepts, ? . 3 . 2 • 1 System ri ode s. a. Immediate Execution. This is the 'do mode' which is invoke;] by touching the 'do Diode* command (t^e t ointiny hand on th"» bottom or the screen). After this mode is invoked, a dotted box appears a ton;: a the 'do mode* symbol and ill subsequent language commands which are touched are immediately performed by the PAL system. If a .stored pi.ogra.ai is touched while in the 'immediate execution' mode, it appears expanded in the 'program space' au ' cin be executed by touching the 'run' V) •v.'steffl command. (PAL returns to tho ' in mod iate execution' mode ifter th : ? program has boon executed.) b. Progra n tfrit in j. The 'write mode* is invoked by touching the • writ**" systorc command (the writing hand at the bottom at the screen) f it which time i dotted ho;: appears around the ' writa mole' symbol. (A dotted 'ox is aLways around one ot the system mode symbols.) A mess dci" requesting that i program name be chosen is displayed. The name may be any cot tin at ion of on« to :our characters. Til*- 1 name chosen hv the chili ippears it tho ton of t ha • program space 1 and ill subsequent. language commands touched ni:o written to the 'program space' ana form -i •program' i he program tuns written is the 'current program' whicn can be Hini' at any time c / touching the 'tun' system command. While in the 'write' mole the program currently being written can be execute?. After t h » program termini tes the system remains in the 'write' mode and the 'current program' may be ad&od to by touching further language com. nan Is. c. Program Editing. While in tht 'write' mode, the Last command entered into i 'current program 1 cm be erased by J 6 pressing the -ERASE- key :>n the plato keyboard, A new program can be started at any time by touching the 'writ*' system command, at which tin a the entire current program is erased and a now name is requested, a stored program may be edited by touch- ing the 'write' command and then touching the desired stored program when the name >f a program is requested- i. Program Execution. A progra.n in the 'program space' (the "current program") can he executed by touching 'run'. (-. Mode Chan gin j. The system is either in tie 'do' or 'write' mode. 2 it her can be invoked ay touching the respective editing command. A program may be 'ran' and the screen erased from either mode. A program may bo deleted (with the 'zap' system co.amanl) or stored (with the 'wrap' command) only from the 'write mode'. iay area'. Th(> 'finger box 1 is ii.so i variable and can be con-pared to a register. Erasing the ' play area' initializes the variables to blanks. The location of the 'active sguare' ani the contents of the 'finger box* can also be "initialized" by assign- ing values to them ana th^n executing a program that will use these values. c. Storage or Memory. The 'store' and the predefined or 'book' programs represent read-only storage, while the programs writ- ten by the children are ^.ivzd in read/write storage. The 'play area' is also rea d/wr 1 te storage which is addressei (as is the 'program store') bv touching the desired location. (If the 'play area' is touched in the 'write mode * , the cartesian coordinate represen- tation o: the touched location is written to the JH •program spice 1 . The child net- 1 not know what the cooed incites mean to write or understand l!i<« program.) > . "-}.>. 3 I'roqi'i ms. 2.1.2.1.1 .ti'ui'Mice of Instructions, i. Static Sequence. Thf* text of the program, its static sequence, is displayed in th«-» * program ppace 1 both while a proqra;n is being executed ini while it is beirij w r i 1 1 e v. o r i e v i s e d . h . Dynani ic So j uen ce. The flow oi control (the dynamic sequence) of i program is indicated by d 'program pointer' as the program is executing. c . P r o a r a in Pointer. A symbolic 'program pointer ' represented by a hand "points" to thr! instruction currently being e xecu tel . i . Synt u. The syntax of PAL is extremely simple. The only syntactically incorrect combination ot commands is unmatched 'loop 1 parentheses. 2.1.2. i. 2 instructions. *. Primitive Instructions. Vg The "assignment st at em out" is explicitly repre- sented by the 'touch store', 'drop', 'pick up', 'join', 'take away' and 'erase' and implicitly by the 'move' command, 'Touch store' assigns th^ picture toac:ne«3 to the ' finder box', 'drop' assigns the current 'finger box 1 vai'je to the 'active* square' while 'pick up' assijns the value of the 'active square' to the • tinge r box*- 'Join' an 1 'take iway' also alter the value in the current. •activ » square 1 and *er*se' initializes it. The commands 'move 1 and 'move ictjLve' change the posi- tion >r iddress of the 'active square'- 'Move' does not change the contents of the 'active square' but the positions in the. 'play area' representing the old and the new 'active sguar< The 'end loop' cocaiand is an "unconditional transfer of control" mi the. 'out' a "conditional transfer on control" instruction- 'Pick up', 'drop', 'move', •loin 1 , 'take away' and 'erase ' are operations while 'set the active square' (touch the 'play area') and 'move active' are addressing commands. b. Composite Instructions. •Loops' and procedures are composite instruc- tions. Procedures are use! in PAL as a structurinj uo mechanism since complex PAL programs aro modular, composed ot several short programs- They are also extensions or the instruction cole since procedures are incorporated into urograms in the same wav language commands are. The symbols for the pro- grains iro stored physically near the commands to help the caildren remember hoy to use the proce- dures. Predefined, or 'book' procedures can be used like the programs the children wrote them- selves. 'Loops' are sequences of commands enclose! by 'begin loop' and 'end loop 1 brackets. 'Loops' are also t red ted as single instructions by the program execution- If control is transterred out of a 'loop' (via the 'out' command), the program pointer always goes to the instruction immediately following the 'end loop' bracket. Both procedures and 'loops' can be nested resulting in a composite instruction . 2. .1.2. 3. 3 determining the Correctness of Prograras- Because the states ano memory contents of the PAL system are visible at all times, it is easy for children to discover ir a program is not doing what they wanted it to. One way of finling a "bug" is to U 1 point to cdcn comma nl and ask tne child what hn thinks will happen when PAL executes that particular command. This process is easier with PAL because the •program pointer' is also a hand which points to each command i s it is executed. Also, the PLA T screen contains i picture of the system parts serving as i reminder or what can be done a rid where things can be move 1 ]. 2.4 Common Concepts not in PAL. 1 . u . 1 Oat a Types (e.g. real or integer) . PAL has only one lata type (picture element) for simplicity; we feel that is sufficient for the intended use of PAL. ?.«'*.? Data 3 1 r u c t ur es ( e . g. ar r a y s ) . [{ere, again, ior the sake of simplicity PAL has no structure] data types. 2.4.^ Declarations. Data declarations are not needed because PAL only roij ports ° np data type and one data structure. 2.4.4 I/O. T his feature is also not necessary because T/o is needed only to make data accessible to the eye. In PAL, neinory and work ar-aa contents .ire always visible. 42 ?.u.s Statement Labels. Since PAL contains no "goto" statements, labels are a lso no t needed, 2.4.f Procedure Parameters. Parameters are not present in PAL in order to keep the system simple. An etfect similar to that of passinj parameters can be achieved by moving the 'active square' to a position where tne program can act on it or bv loading the 'finger box' with the desired contents betore running a module. (See the maze example in appendix E.) 2. 4. 7 word Lengt h . All "words" are of the same length, therefore this concept is also not needed. ? . '4. R Counters. Because oi t'AL's simple loop structure, counters are iiso not nee de i . 2. 4. 9 Fecursion. Only certain limited forms of recursion are possible because PAL has no procedure paraue ters. Also, when writing a program, its name is not yet in the 'program store 1 , mar.ii j it cumbersome for i program to invoke itself. Thus, the full concept of recursion is not present in PAL. T* \ Lx poriments to Determine how Progra nutting Concepts arc? I.e. i me i, 1.1 C;i.')« Studies in Teachiny PAL. 1,1.1 Preliminary studies with Several Children. Three children were used in the preliminary studies: Patrick, age 12, Jodi, aye 11 and ^ike, also 11. ML three had completed the fifth grade in a Champaign, Illinois public school. These preliminary tests helped us understand what to look tor when testing children, what to emphasize in introducing P\L and which concepts to introduce First. For the preliminary session we deciied to work with children in about th* 1 fifth grade, slightly older than the children PAL wis designed lot. Their exposure to PAL consisted of i totil of two sessions (see appendix C) , but. they learned to work with the system quickly and -•nloyod programing with PAL. One ot the conclusions Leached fro.n the preliminary sessions wis that it is tetter to give: the children little help, to let them experiment o.\ their own, 3 . 1 . '? T i m my a n i V id e o Ta ping • At the start of the sessions, Tim my was 7 years, 6 •months old and in thf* second grade or i champaign. 44 Illinois public school. John Clement.1 helpel with the i i: tor viewinq and introduced Timmy to PAL. Pimmy participated in 12 sessions which were video taped. Sessions 3 and weio in formal with no instruc- tion and were held at Timmy's school. They were desicjnel to let Timmy practice with PAL or' his own ind proved to he quite valuable in that thsy stabilized Timmy's know- ledge of PAL. The later sessions were further apart which hindered Timmy's progress since it look longer for T n: to rea quaint himself with the system. Timmy was often fidgety because the sessions were too long for someone tnat young, but shorter sessions would hive been impractical. Several improvements to PAL were developed from the observations with Timmy (resulting in version 2; see Appendix A for the differences between versions 1 and 2) . 1.1.3 Linda and Audio Taping. When beginning her work with. PAL, Linda was q years, 1 months old an 1 a fourth qrade public school student from t. no nortawest sile of Chicago. We tried to utilize the experiences v, ith Timmy to improve the sessions. One decision was to use a child slightly oiler than Timmy and to try to hold sessions regularly twice a week. We felt judio tapes alone would be sufficient since we knew more U5 or whit to Iook. for and would not need vi Ipj replays. M oreover, audio taping would provide fewer distractions to Linda. one of Linda's favorite activities was forming words on t lie PLATJ .screen. When she arrived at home, Linda tried to describe PAL to her family and was very happy when she was given a picture of the screen layout to help with her descriptions. According to her mother, Linda ruijoved usin i PAL ana looked iorwirl to her sessions. After the tinal meeting Linda had the opportunity to show n Al and the programs she had written to her L imiiy. 1.2 Hapiple Protocols or .Sessions. ^h' 3 transcripts of several sessions hav«> Leen picked is samples and used to illustrate the progress the children mad' 1 between early \ nd later sessions. They are Ix y no mean;: meant to be exhaustive. Section 3.4 will reference these sessions where applicable. Each protocol i :i this section is introduced by the session number, b y how many minutes had elapsed and, where relevant, what had occurred to that point. The protocols appear in two columns, the left is the tran- script of what way sail (the actions ar*- iescriLed in parentheses) and the right column our observations on the Ub occurrences.. An -H- in the right column indicates that. Mm child rccelvel help it that point, -ii- that a mistako wis nade and -I- indicates the chiLd had an idea of his )w n. U7 \.?..'\ Tim -- So so ion c > : Tiramy Gains a Clo.irei ; J nde rst a nd i no of P ro gramm in q. In session *5 Timmy star, tod out being vory unsure of program writing. John provide 1 extensive help with the first program, and later in the session Tim wrote one with verv little* help using the commands 'cove' and 'loop'. To thin point ho nad been exposed to PAL for three, hours 4? Minutes and to writing programs for a total of two hours, 20 minutes. A K T /■> c: rip t : ii'^i ;. n i ■ l ■: ofc session r > ( T i. m r. y drew pictures on his v«?n while John and Ha una readied the video machine. After 7 :ninut«s, Tim touched the 'write ' system command and asxed John how to spell •city'. Ti ni then named his program 'city' and asked:) 'low what do T do? What lo yon want to do? T want to writo a program rut 7 to root what i dj. Timmy is very guick to ask: "what do T do now?" He needs hints along the way at this stage and is unsure of himself. J: OK, what would you like the program to lo rihrtn yo u • ro d one? -H- r: i*'alk. tfalk up and down. J: Then w-» touch the 1 things we would touch to a .1 ,\e the I • rsoi. walk , .or, L y ho doesn't walk right away, 1 1-. ■» y jiiot corae ov«r here (John points to the ' pro- 1 r j .; ;; L oi ' ) . Tim seems to know what program can do. -li- re John rev lews the a co m mauds. idea of writing sequence of u f \ '•'hit do you rae.-ii: i pi ico anywhere? T touch Yea, you h.ive to y^t some- body. You should probably uick him up, wnoev»r you want from the 'a tore 1 to W A 1 1 . John is trying to give Tim- a hint to program the sequence: 'store', 'pick up', 'set play area', Mrop'; Timmy is not responding to the hints. Z\v, I make two things walk at the; same tine? 'That's harder but you can io it. tfhy don't we make of)-' person walk a nil then I'll show you how to put the other person in. OK. I'll oiako him walk. ("in touches in the 'play i r e a ' , k A a p pe a r s i n the 1 pro jtri.il space' . ) ■: h it h a ppened ? Tim is thinking of pr og ramming to ma k^ pictures move, not of * pick up' a ni Mrop 1 commands. He is not paying atten- tion to John 's leads, ?im wants to figure out what to io cy himself. tie is gaining conri- dence with PAL. -M- 7t does " ka", (Tim pauses to think) I wuit... ( ? i m touchoo different squares in the 'play ar^a' and sees the coordinates appear in the 'program space'.) J: So why don't Wk! pick up a person to do the talking? T: That one. (Tim points to a jirl holding a t lower which he previously put into the play area.) .7: ^irl with a flower? OK, then why don't we maKe her go up? Will that be good? :' : yea, that's what I want to io. Tim is used to 'immediate execu- tion • mode and is wondering why th3 Mctive square' ifin't appearing at tne spot he touched iu the ' play area '. Tim my knows which picture he wants. U9 Then lot's put the box arou nd t he girl. Ciiiti! y touchPo girl eiasf-s the entry in the pro gram - touches again) Mow, "i m , when it says iA hero (joints to the iA in the 'program spac- 3 ') - see the i A ? Here T im forgot how "touch" works while in the programming mode, he is expect- ing the • act ive square" to appear where he touches. iO-( m Ldtnr on, when we push nir., when the arrow (the r Log Lam pointer was an arrow in version 1) cones no wis the program and it -i'p:; the iA, it will put th e hox {the • act iv e square') around the girl. So tha t • s good . ijiidt will she do, go up or down? N'o, she isn't join j any- where yet, cause wc didn't put any arrows. So, maybe we oetter get some arrows. '■' n ij h w ay do you wa n t he l to JO? wan t her to go ... (touches the 'move up 1 six tines, then the 'moves' 1 eft , lown and right) „ tfoul-1 you like to try it? (";"i touches the 'move down' two more times,) Tim my isn't thin kin j a ;> o u t h o w a pr o g r a m wor ks. He nee ] s more practice witn p r o g r a m ,u i n q to q e t used to thinking i:)out commands which are stored and can executed at he later time. Because Tim still isn't getting t n a idea or programminj r. h e 'pick up', • d i op' segue nee, John goes along with Timmy ' s train of though t. 50 J: J: J: .:«, push the Lunnini boy to make it do tho program. (Tit, touches 'run* and wdvns his hand over the .screen in a circular motion as the program executes and the girl moves. At this point the program consists o* the statement "iA" and 11 ' n o v e s • - ) It's going down the pro- gram, isn't it? See the arrow? It's going right down the program. Can T make it run again? Yea, let's do it again. (7 i in touches ' run ' , messages appear. error Since her is now nothing at location fails.) iA, Lh< ui o v e •!hat happened? box? (Poirts •active square' , ] ocat ion iA. ) See the to the now at Timmy is overjoyed to see the girl move the way he had directed her to. Ti m d stand s j ua re around since that t mind wis s ] u a r e (The before execut progra oesn ' why t wa th he he £ i in hi " move to t girl th ion ra.) t under- lie active sn't put e girl thought rst cor s program active he girl", was at i A e first of the I ant it to move J: It (the error message) says, "that command railed, there is not hi n ] to move". ( t i m m y w i t h a sg ua res ' ictive the program execut ing an 1 in turn ta ils. ) t ouches flower, higher square ' . the now tha n girl two the Mean w hi le is each still move' No w hv * r, manu ally trying to place the Mctive sguare' around the jirl, not realizing that the commands will not be •immediately executed 1 while the program is running. -H- 51 See that ( points to poi nt«r) , Tim? ai_row there the program t e i . Tt (the progr counts ah'] sees arrows. It com to move what ' (* act ive squa Mi ere ' s no th ing So T guess the works whon we thing there ] oci t ion LA) to a "- cai: pit some (Joh n brief Ly ' imm of] latt exec and helps Tim e im pointer) one )f these es an (3 wa nts .-, in the uox re' ) , but in th a box . program only have some- (pO Lilt J to start with. thin j there, o x p 1 1 i n 3 t h o :i tion* mode v o k e it.) (Timmy puts in umnrelld from the 'store' into posi- tion i A and erases the girl v it h t lower. ) M o w w o r k think 'city' will Here's city (points to stored program touching it ) . the program bac^ without If we get f o r city John briefly r e v i e w s program execution; TitRiny nee is frequent repetions of explanations. -M- Ti m did not get a systematic introduc- tion to modes a n 1 mode c h a n g i n j previously. At this point Tim doesn't carefully think through what he does, but, we feel , is gainin j correct intuitive feelings about what may work. Oh , T k now do. We run (touches wait in g no th i ng ha ppens) what wo need to i t , don't we ? •run' without for ax answer. Mere Tim is begin- ning to get the idea of what it means to execute a program. 52 J: Pus} 'city 1 . You nave to push city tirst to toll it uh.it to run. (John touches •city' in the 'program store', then 'run'.) Here cones the program, there s he go > j s . (T h e p c og ra m moves the umbrella.) (At this point Tim my starts a new program -- not transcribed- ) T i m m y Knows that 'run' executes a program, but has difficulty realizing that the 'active square 1 must be -irouni a program before it can be 'run'. (This is not necessary in version 2.) I got an idea, (Tim puts girl an i umbrella in iA using thn 'immediate execu- tion' in o 1 e . ) -I- Can we nake her jo up? 'fea (Touches 'city', then ' i. un) . (The proqram executes and moves the giri wit a the urn brella! ) At this point it seems as if Tim my knows how to exec at? a program that has oeen stored. 'J.'int a puzzle? I got a problem for you. (John erases the 'play area'.) I want you to see if you can make a program to ... If I put a car over here (John puts a car into location a A of the 'play area'), can you do a program, Timmy, to make a c ir move over? 'low m \]\ v? i"cr to F (position iF). I'll try to. Do I hive to name it? Tin my needs to be given ideas and he quickly picks up on them. Idea seeds from adults were valuable in that children could expand on them. In a classroom situa- tion children giv;> oicn other ideas. 5 J J : Yf.i, in order to writr the pro I ram, you have to push 'write' . (Tim touches 'write', names bis program and touches a A as the first instruction, J John repeats the instructions for beginning a program; Tim needs frequent reminders. a A , that's wherp you i t ? want J: Yea, that's where it is (the car is located at. aA) . !qw what do do (before he completes the question, ' move rigli t ' thou 'run'. executes a nd one position Tin; touches 6 commands and The urogram the car joes too car.) Farther ! J: Hissed by one! Can we fix i f ? What will we have to do to only make it jo to f? (Tin' nresses the er ise key, thereby erasing the Last 'move' in the program. Without testina the pro- gram, Timiny touches 'wrap* to store it. ) Asking what seems to be a with Tim. does know wha and demon that he can, h .? 1 p , /rite gram consisti starting posi the 'play are ' tio ves ' which the contents starting posi to do habit Mere he t to do st rates with no a pro- ng of \ t i o n in \ * a nd act on of the tion- Here ?in>my seems sure of himself. 54 3. ?.-?. Tim -- Session 14: rim my Debugs ero^rams a nci Uses Loops. In this session Timmy wrote a program using 'moves* contained in a 'Loop', and used the program to move several different pictures. lie had been writing programs for B hours over a period of 5 1/2 months prior to this session. !_?_ A_M_ J_C_ R_I _P_T_l . j r ) ininuf.(-s into session 1U. T: I can make that witch go (points to a witch superim- posed or. a car in the ' pia y area ' ) . J: whore? Hare Timmy idea for a by himself. -I- gets an program T: hack and forth, \ o you want to see it ? J: Yes. (Tim touches 'write', names f'ne program 'rfty' and w r i t es the command s: ' move right 1 , 'move left', witch, 'drop 1 , fD.) T: And that' 11 work. .1 : >:hdt will it do? r: Tt'l] move it. back and forth. I bet it does. J: what's gonna make it go back and forth? T: "hat little (points to 'move' commands in the pro- gram, then touches 'run'). Timmy doesn't need prompting at this point. -H- Tira writes the pro- gram quickly, impa- tiently; he doesn't think about indivi- dual commands. He sees arrows, a witch and 'drop* in his program and doesn't think about the order. Tim does know what the 'move' command will do, but doesn't put it into context. 55 (The program executes and since tho 'active square 1 is around the witch in the •play area', the witch moves back and forth once.) ok, it did at. the begin- ning there- Oops. (Execu- tion of the 'drop' results in ^n error message since the 'active square' is occi] pied . ) Heh. John tries to guide Tim through steps of debugging- Tim doesn't want to take. time to analyze. OK, p. rroi went hick o we got a couple of messages after it and forth once. Right. Nov why did it do that, T im!ii y ? T don't know. Stop a minute. I'm gonna ask you. What happened? [Tiromy was about to touch the screen in order to change his program.) Should have put that first ( points to the second part of the program, the witch, •drop', fD). Oh, all the stuff to get the witch and th" car. (Tin; prases his pro; ram and substitutes: 'bog in loop', 'move right', 'move left', ' end loop 1 . ) Timmy is still guick to say that he doesn' t know. When John pins him down, Tim does know why the program tailed , at least generally- -I- I bpt that' 11 work. 56 J: UK, what do you think that'll do before wo run it? T: Ft hits that loop and goes that way all over (points to 'oti.l loop' and then back to ' begin loop* ) - .1 : And what will it do on the screen? 7: iU ldke the witch jo back and forth on the car. ■J: flow long? T: \s lonq as I want it to. J: Really? T: Yea. J; OK, here goes, we're gonna run it; (Touches 'run', pause) back once -- what's h a n p e n i n g ? T: It's going back and forth. J: (Claps) He solved the pro- blem -- I told him I bet he couldn't do it, that he couldn't make the witch go back and forth on the car forever and ever. How long do you think that'll go, Timmy? T: As long as -- it can do it all night. I bet if we go down an! have a pop and we get back that thing will still be doing it. Timmy still writes programs without analyzing them very well, but he has more of a feel for what they shoull look like, for the s^guence the com- mands should appear in. T im added the loops with no help. -I- Here it seems that Timmy displays an understanding of loops and the abili- ty to analyze com- minds in a program. A very definite answer. Tim seems very sure of himself. 57 J: And not yet t ited? T: Uh, ah (shakes his head). J: OK, question. What Jo you have to do it you want the tree to go back and torth like that? Hare Timmy appears to display an under- standing important about that they on doing ate told of an concept computers, will keep what they to do. T: Same thing. J: Can you do that real quick? T: Yes, watch. (Tim touches tree, which put.--, it at the end of the program, i.e. the program is now: 'begin loop 1 , 'move right* , 'move left 1 , 'end loop', tree.) T: OK ..-• no, that won't work (erases tree, stores the program and goes into 'immediate execution' mode: puts a tree into play area and touches 'run' -- the program now moves the tree back and forth) . J: before you hid a witch over here on a car and rfty (Tim's program name) was moving the witch back and forth. Now you have a tree here and it's moving the tree back and forth. Timmy, before you touch anything more, I got a question for ycu. (Tim was about to touch the screen.) W hat. Is there anything this program can do? Again, Tim writes a program very quick- ly, but he is get- ting a better feel- ing of what sequence of commands to use. -I- Timmy is more confi- dent about changing modes, and executing prog rams. He an is also showing understanding about how a program works, that it can act on the contents of the present ' act ive square 1 . Tim is fidgety, anxious to try things out. He wants to make things happen, experiment, not analyze. else S3 T: Let roe think. J: Before it was working with a witch, now it's working with a tree. T: No. J : It can't make anything else move? T: Yei, most everything. 3 : \ helicopter? T: Yea. J: Smoke? T: Yea. J: Anything else? T: Yea, everything. J: Oh, OK. T: I could probably make a girl on a bicycle go back and forth and -- J: You sure? T: Uh , h u (nods) . .1 : what makes you sure? T: Well, I just know. .7: Could it make something go up and down? Timmy misunderstands what John means. He thinks John wants the program to do something other than make the contents of the 'active square' jo back and forth. Mere Tim seems clear about what the pro- gram does but doesn' t want to describe the program step by step. Again, he is impatient. T: Ye»- 59 J: You just put the witch here and what would you do to make the witch go up and do wn ? T : I'll show you, J: ok. T : I'll make the tree j o up a n d d o w n . ( T iir, starts a new program consisti ng of: 'begin loop', 'move up', 'move down', 'end loop', 'exit 1 ; and touches 'run'.) T : It's working! J: it's going up and down? T: Yon . J: Far out! -- Does this exit do anything, Tim? T: Yea. J: What does that do? T: When it wants to stop it, it is on the re- el: When it wants to stop it, what ? T: Vhen you got the loop started going like straight across, wh^n it gets to the rr.d it stops. That arrow (program pointer) stops so it won't say that command failed. When faced with the problem of making things go up and down, Tim realizes that he has to write a new program, -I- de feels confident in writing the pro- gram, but is plea- santly surprised when it works. -In- putting the 'exit' in the wrong place is a minor error. He does appear to understand the prin- ciple of ' loops' , •exits' and of pro- gram pointers. -r- Whit would happen if you didn't havo the 'exit'? 60 It would say t ho command failed for a long time; till I go " ba c k , back, bick" (presses the -BACK- key which stops the program o xpc ution) . (John explains that the 'exit' has to be inside the •loop'.) Could 'rfty' make the tree go all the way across? Cause then you'd really need the ' exit * . He has the idea, even though he can't verbalize it very well. Here Tim shows that he knows how to get out of a loop by interrupting the program execution. -I- (Tim erases his pLogram and writes the commands: 'begin loop', four 'moves right', 'exit', 'end loop'.) Now Timmy doesn't hesitate in writing a program and shows confidence that the program will work. J: Now before we start, will it do? what Do like you told me, watch (touches 'run') . 61 3.2.3 Linda -- Session 2: Linda is Introduced to Programming, In this, Lindi's first, exposure t.o program writing, she gradually learned to write a program which put pictures into the 'play area'. She was confident in using all commands in the •immediate execution' mode and had been exposed to PAL for ohe hour. TRANSCRIPT 4f>j inn j_nj_of_sessi_on_2. (Linda drew pictures tor 12 minutes after whic.i time Hanna introduced the concept or pro- gramming. Atter the dif- ference? between 'do' and •write' modes was explained, Linda touched 'write' and naiT. ed her first program ' t i n a ' . ) H: Try something. You mean like I touched a car . H : Yes, go ahead, touches a ca r 'store '. ) Now what happened? (Linda in the Linda is hesitant at first, she doesn't seem to understand the explanation of 'program', she needs to experiment with the concept herself. L: The car went over there (points to the 'program space') instead of in the box ( ' f i nger box ' ) . (Hanna re -explains the meaning of a program and that Linda is now writing one. Linda touches bicycle and vw. After Hanna explains how to run a pro- gram, Linda touches 'run'.) Jhe does see that a program is being formed, but not guite what the pur- pose is. -H- ilanna again explains the difference between 'write* and 'do' modes. 62 Vow what happened? The things that T out down (into the program), the hand ('program pointer') went to thorn and lp pea red thorp (points to the 'fin- gee box ' ) . (Hanna explains whit hap- pened and what •run 1 does.) Linda does see a relationship between the things she did earlier and what happened after touching 'run'. l: Before, when the dotted box war, arouni the hand (the 'do mode' syinlol) , how would you put something in the play area? L: I would touch one or the pictures, then toucn where T wanted it. H: OK, why don't ,-ou try it. L: OK (touches the house in the 'store') . H: Then what wouli you do? L: Then I would touch the 'drop' and it would come in here (touches the 'active sguaro • ) . \\ : Co ahead and try it. (Linda touches 'drop'.) L: It won't do that because I have the program H: It won't do that now, but we can make it do that lat.^r, anytime wo want to by pushing 'run'. Push the 'run' and see if it'll do t nar . Here Linda does not ]uite understand the relationship between the commands in the 'immediate execu- tion' and 'write' modes. She needs practice to see for herself what a pro- jram does. -H- Linda seems to un- derstand that writ- ing a program means that the commands won't be immediately executed, but not why one would want to do that. 63 (Linda touches 'run', the program ' t i n a ' , consisting of douse and 'drop' puts a house into the square which is currently active in the 1 pla y area '. ) There it goes! Either you can add to this program or do something else. What would you like to do? Linda wrote the com- mands on her own, but not the program since Hanna gave her bints to use the same commands she wjuli use in the 'immediate execu- tion ■ mode- Ad 1 somet hing- OK, jo ahead, try it. (Linda adds car, bicycle, Vrf, sun, 'drop', tree, umbrella, 'drop' ml slower to her program.) She appears to enjoy programming since, when given the choice, she wants to continue with her program. (Hanna erases nf play area' by touching 'broom* and Linda touches 'run'. Kheri the program executes the second 'drop', a fail- ure message, that "Th^re is already something in that space" , appears.) Linda is not sure what the commands in a program mean, but she sees that they appear in the * pro- gram space'. Why is it saying command failed"? "That Because I 1 1 r o p s ' . Can't you ' drops' ? have two nave two Mere she analyzes programs a little. No. H: Why not? L: Because then if T hid one hero to put th< j sun down and if I had this here it won't put the witch djwn in the same nox. Let try another one ( p rojnrn), OK 3 u i s*-! that one. (Shows Linda how to erase the commands in her program by pressing the erase ke y) - 64 She associates the meaning of a 'drop* in a program with 'drops' she is fa- miliar with in the 'immediate execu- tion' mode. (Linia wants to 'play area ' .) f>rase the Now how do you jet it to erase? (Linda touches the picture of an eraser, the •erase' command is added to the program.) It iidn't erase the screen, did it? Here Linda is learn- ing the differances between the 'write' and 'immediate execution' through practica 1 experience. No, you ' re ( 'immediate mode) . cause that's when drawing a picture execution' Do you think you can tell the computer to put a house h^re and a girl there (points to the 'play area') ? ( V3 second pause) -H- Weli, before, when we were just doing it without writ- ing a program, how would you put a house here-? By touching theie (touches in the ' play area' ) . flere Marina didn't have to tell her to "go ahead and do what you would do if you were drawing the picture in the 'do' .node". 65 H: What happened? oA went ii. the program. (Hann^ explains what the coordinates mean.) Then what would you do to put a house there? (Touches the house) and the house didn't tjo there because it's remembering (the program is remembering and not "doin j" the commands) . Is that all you nave to do? Yea, because wh en t ho hand (program pointer) comes here it would know to go here (points to iocition eA in the 'play area') and if you put a house up there (points to the 'program area') , it would know that the house should come t here. We can try it. Try the •run'. You told it to remember, and then you say OK, do it . (Linda touches 'drop'.) OK, want to try it now? (Linda touches 'run* -- the program puts a house into the 'play area '. ) For the first time Linda sees that something other than a 'store 1 picture and 'drop 1 can be put into a program. Here she demon- strates that she un- derstands the con- cept of ' program pointer '. Both she and Tim my often thought that the computer would "know" to do something. This shows that she is thinking about the commands and realizes that tne computer would not "know" to 'drop' the nouse, that she must tell it to do so. 66 This'll put a house there evf»ry time we ' lo' it. Tne next time we 'do* it, wh.it ' 1 J ha ppen? Tt won't work unless you erase the house. Can you erase ths house? Py the broom? (Linda touches 'broom'.) wood. Now let'r; run *tina' again, (Linda touches 'run'.) S o a pr og ra m is an easy way for us to do some- thing once and save it. (tianna asks how Linda things a program is put away and saved, Linda points to the 'wrap 1 edit- ing command.) Yoa, wrap it up and nut it away, push it. {Linda tourihes 'wrap'). Where did it. put the program? Here (points to 'tina' in the 'program store'). Linda seems to un- derstand the idea that a program "remembers" the com- mands and can wKecute them at a liter time. She did not have any trouble saving or •wrapping* programs. 67 3.2.4 Linda -- Session 4: Linda Writes a Program using 'iovp'. Tn this session Linda wrote and then analyzed a program which 'joins' a boy with a bike and moves them across the 'play area*. Linda had written programs for one hour in session 2 and one hauc 20 minutes in session 3. h H S C P I P 20 minutes into ses^iinn_'j. (Linda had written programs to place 'store' pictures into the 'play area • - ) U : Can T ask yo i to w^ite a program that'll nut i boy on a hike in the low<^c left hand corner and then move it all the way icross? (Linda touches 'write' and calls her pro j ram 'sue*. She then touches a A, boy, 'drop', bike, 'join*, then pa uses, ) H : How want way across. do you move it? I you to move it all the -M- (Linda touches aA, 'move right', bA , 'move right', cA, 'move right', dA, 'move right', eA, ' !;-.ove Light', At this point the program is filled, Linda touches •run '. ) Linda understands that an arrow ' moves' a picture, nut ls unclear about the fact t ha t it also moves the cur- rent address of the •active square' . '!er program does work, however- 6ii H: Wor ks O xoc utes a bicycl aiwl rao pict ures of the f A , not across. ) N o w u h a t he pro poi n ts command a A, ho • join' , Of 'Sets and asks the com in ! (Th and pu e onto p ves the across screen < ] u i t e a 1 OK, p t does points t ■jram. to each in the aA and t 1 and 'in L inda ands :) e proyram ts a boy on osition a A compos it e t h o bottom to position 1 the way retty good. t hi^ do? o the aA in She then success iv e progra m: op • , bike, iie sequence ove rights' to explain L: It puts the active square (points to lower left cor- ner, position aA) . Manna is trying to have Linda analyze her program step by step. The sequence of com- mands neeied to put pictures into the 'play area ' seems clear to Linda, even when they occur in a program- It (the bov) joes in the 'finger box'. Then this (points to the '.irop') makes it come here (points to position a A) . She understands what the commands do and is able to analyze a program. Tnat (bike) goe.s (•finger box ' ) . in the bo x It (the 'join') puts (the bike) on the boy. it H; OK, why does it put it on the boy? How does it know to put it on the boy and not iiu here? (Points to a position in the upper por- tion of the 'play area'.) Because those* are commands, 0K # qood, T'his means 'join 1 , it means join what to what? 69 L: The hoy with the bicycle because he's in the 'active square '. K: '5ooi, right. (T.inda con- tiauis with her analysis,) L: That (points to position aA) moves the active square to there. H: Shore was the active square before this? L: It was there (points to aA) . tl: Piqht, so this isn't real- ly necessary- Now what does this clo? (Joints to the first 'move right'.) L: Tt moves it over to that (DA), H: What does it move now? L: It moves the boy and the bicycle, H: And? Does it move the 'active square', too? L: Yea. U: So now what does this do? (Points to bA, the next command in Linda's program. ) Lt seems clear t hat- Linda also under- stands the function of the 'join' command. Because the children do not see the •active square' move while they are writ- ing a program, they often put in extra •set* commands; to be sure that the 'active square' will be where they want it. This, again is because it is diffi- cult to translate the commands in the program to corre- sponding actions when the program is executing. 70 L: That moves ( he sit a tcs) — that movos — (paujes) — that's where the active -- that doesn't move it but it was there, (Linda erases the program and rewrites it; aA, 'hoy 1 , 'drop' ^A, bike, ' join', bA, anH 8 'moves ri jht'.) H: '-.'hat does this uo (points to bA in the new program. Ll ve be st sh sq ia wh an Sh ' m ac we CO [1 da ry g iii n and ip o uare ngua ich d i e ove' t ive 11 nten mak her ing th f t i ge ac ts re a a es e! a di Sh to un e relat he • ac with COM t upon conte lizes ffects square as sco- e is der- ion- ti ve the a nds it nts- tnat the as the tS. It doesn't. move the boy there, just the box (•active square* } . -H- (Lin da rewr part of hec 'sue • now co boy. • d r o p ' 'join', a A , right' at wh was no more prog r a hi . T ' i un • , the p a n 'i puts a b at. p o s i t i o n to i A, one p the right ed area '-) ites the last pre j ram so that nsist s of: a A, , aA , bike, and 3 ' mov es ich ; oint there room in the lien s;ip touches rogram executes oy on a bicycle a A and moves it osition before ge o r the 'play with a little hint Li nda discovers her own error. -I- 71 3.?. l 3 Linda -- Session 6: Linda Learns about Subroutines ml user, Loops. Here Lin la wrote a program which called subroutines and incorporate! 'loops*. Loops were introduced in session r > where Linda worked with the concept for one hour. Before session 6 she had used programs for a total of four hours, 40 minutes. P T Five minutes into session 6. (Han in pr o gr a ,t city, w it h an of pu trees . g ram ' drop' , •drop' , • drop' , •drop' ; gram i s •run' , into t sh o r t o suggested L to creat She sugges «r-3sier pr tting down L in la sta r ' tree ' : bG, 1G, fG, at this filled. a row of he 'play f a full ro ' d t •d DO " L 7 i rid a e a tod ohle a ts t AG, rop • J rop rop' int i nda tree i rea w.) wl it e a whole starting r,, that row of he p ro- te ee, CG, eG, / g g , the p r o - touches s IS put i __ 3 Linda shows confi- dence in writing pr ogra ms, tl : Eh, pretty good. Would there be some way }f doing the same thing but patting it. in a 'loop'? 'lore's aG, where • s bG ? iiinna begins to introduce the 'move active' command. L: One over. H: Is there some way of put- ting the active sjuare one over without touching? -H- 72 m;i it. A message appeared requesting i press of the -NEXT- key if * new program is to be wiitten. (In version ? no message appears, the child has to touch 'write' to start a new program.) 81 J: Do you want to make a program or do you just... T: No, I don't want to make a program. J: OK, then you have to push this square (John touches 'immediate execution', later called 'do mode'). That's the opposite of this one (points to 'write*); that means you don't want to write a program. At other times John mainly helped Tirrimy invoke the modes when it was required. (See section 3.2.2, the partial transcript of session 14.) Linda was first introduced to 'do mode' as a system command for 35 minutes in session 2 (see section 3.2.4). To get Linda used to the 'immediate execution 1 mode at the end of session 2, Hanna md Linda executed the programs Linda had written earlier that session. Five minutes into the session 3 Hanna asked Linda to write a program which puts a garage around a car. Linda had used 'join' in session 1 (in the immediate execution mode) to put vertical and horizontal lines around a ca r to represent a garage. Because Linda had just written a program, she was still in the 'write' mode. For about 15 seconds she contemplated the problem, touched 'immediate execution', then 'write' and again 'immediate execution'. After drawing a garage in the 'immediate execution' mode, she again R2 went into 'write' mode. The above indicates that, by session 3, Linda was very confident in invoking and using the 'immediate execution' mode and used it as a reminder of which sequence oi commands to use for a particular problem. 3.1.2.2 Program Writing. The conceit that a program is a list of exactly the same commands one used in the 'immediate execution' mode seemed to be the most difficult concept for the children- The idea of a program is abstract; the children don't see any results until it is executed, at which timo they find it difficult to see the relation- ship between the command they had touched long ago and the events happening on the screen. On the other hand, the concept of touching 'write 1 to go intc 'write 1 mode to start a program was easily and guickly jrasped. The children understood how to start a program, but not wuat to do nice they were past naming It. Timmy, for example, touched 'write' very confidently and also named the program, then usually asked: "Now what do I do?" (See section 3.2.1, the beginning of session 5.) In session '4 John asked Tim to write a program to 83 make a balloon 90 all the way to the top of the 'play area' and come half way back down. Tim my touched: •pick up', dA , 'drop', balloons, followed by several •moves up' commands. This ssems to indicate that, by session 4, he had an idea thdt a program is a list of commands to be saved, but was not sure of the sequence of commands nor was he able to analyze what the commands woull do (without seeing them execute). Tim could accomplish the task veiy easily in the 'immediate execution' mode; thus the difficulty most likely lies in translating the concrete commands as learned in the •immediate execution' mode to abstract commands in a program. By session 14 Timmy was confident with writing programs. Svea though he still asked: "Now what do I do?' 1 , he didn't wait far an answer (see section 3.2.2). The time Timmy spent learning to program: Session 2 -- 50 minutes. John helped Tim write one program. Session 3 -- 40 minutes. John reintroduced programming and helped Tim write two programs. Session 4 -- 50 minutes. Timmy still needed help with writing program, but less than previously. 84 Session 5 — 33 minutes. T i in gained a clearer under- standing of programming and wrote, on his own, the program 'city 1 which consists o£ fA and 'move' commands (see section 3.2.1). Session 6 — 23 minutes. Tim had more confidence in writing programs and wrote one containing a 'loop'. Session 7 G 8 -- f>0 minutes. Timmy practiced using PAL on his own (Hanna was there just to answer ques- tions) . He chose to write programs, not just to stay in the 'immediate execution' mode. On his own he wrote the programs 'copy' which put a car into the •play area' and moved it to the right using a 'loop' (containing an 'exit') and 'zoom' which also put a car into the 'play area' and used a 'loop' (with 'exit') to move it up. Linda was ficst introduced to program writing 15 minutes into session 2 (se a section 3.2.3 for the transcription). Five minutes later Linda understood how to begin writing programs md how to name them. der first programs consisted of a series of 'store' pictures which, upon execution of the program, would appear in the 'tinger box'. The translation of famil- iar 'immediate execution' commands to commands which do nothing but appear in a program was also difficult for 85 her. She too had trouble seeing whit the command in a program would do when a program was •run*. Linda gradually learned to use more and more com- mands in her programs and, by the end of session 2 (after one hour of programming experience), was confi- dent with writing programs which put pictures into the 'play area'. Mot until much later was she able to extrapolate and realize that all commands which can be used in the ' immediate execution' mode can also be put into a program. At the start of session 3 Linda explained what a program is: H: What is a program? L: A program is something that the computer can remember after you drop something. In session 3 [{anna aslced Linda to write a program which would build a garage for a car. She thought about it, went into 'immediate execution' mode twice to remind herself which sequence of commands is needed- After 10 minutes Linda wrote the program 'cat': aH, car, 'drop', aH, vertical line, 'drop', aH, horizontal line, 'drop', aH, slanted line, 'drop 1 . Tn her program Linda used only commands which she had previously used in a program. She then touched 'run', but before the fifth command was executed (tha program had not yet 86 failed), Linda said: "I don't think it's cjonna work." (The program would have failed because it would try to •drop' lines on top of the car.) Hanna pressed the -BACK- key to stop the program execution and asked why. Linda indicated that two pictures can't be 'dropped* onto the same square, that 'join' must be used. She then replaced the three last 'drops' in her program with 'joins'. Execution of the program put the hori- zontal and vertical lines in the correct place, only the slanted line ended up on top of the car. Linda discovered her error and immediately changed her pro- gram so that the final execution put a car on the screen and a garage with one slanted wail around it. The above sequence of events took a total of 30 m inut es. Hanna then asked Linda to use 'move' in a program; Linda required 15 minutes to write such a program. This appears to indicate that each successive command which she learned to use in a program took less time. The time Linda spent learning to program: Session 2 -- 1 hour. Linda was ablo to program using 'touch store', 'set play ar^a' and 'drop'- Session 3 -- 1 hour, 20 minutes. She learned to use 'join' an" 1 • .Tiove '. 87 Session U -- 1 hour, 5 minutes. Linda learned about addressing (recognizing the coordinates in the 'play area') and sequences of 'moves'. Neither Timmy nor Linda had difficulty editing programs; pressing the -ERASE- key to erase and then replacing the last command in the program. Both were introduced to the concept in session 3 ind needed no help in using it after that. Recalling a stored program to edit it was more difficult. (This feature was not available in version 1.) Linda was introduced to the concept briefly (for five minutes) one hour into session 3. In session 4 she was again told how to edit a program and 15 minutes later recalled and edited one she had written earlier. 3.3.2.3 Program Execution. After having written a program, the children found it very easy to touch 'run' to execute the program. See section 3.2.3 for an analysis of Linda learning to •run' her program. Timmy was helped the first few times in which he wanted to execute i program. Section 3.2.1 shows that he had no difficulty with that concept by session 5. Executing a program that had been stored was not as easy. This involved two steps, first touching the 83 program from the immediate execution mode, then touch- ing 'run 1 , At the start of session 3 Linda looked at hec programs in the 'program store': K: Want to try one? How do you make the computer do the program that you wrote last time? L: You press the program (touches the program which then appeared in the 'program space'). H: Now how do you make it do it? L: I press the running boy. One hour later, Linda was in the 'write' mode and wanted to execute a stored program. She erased all instructions in the current program and touched the stored program 'tina'. Linda was surprised when 'tina' became the first instruction in her current program (she had not been introduced to subroutines). Hanna explained what had happened and that programs can only be recalled from the 'immediate execution' mode, after that Linda was able to execute stored programs by herself. rfhen sue did make the above mistake (that happened 1 total of two more times), she immediately corrected it herself. Section J. 2. 1 describes how Timmy learned to execute stored programs. In version one a program doesn't 89 appear in the 'program space' when it is touched, the "active square indicator" (dotted box) appears around the program name in the 'program store 1 . To recall it (and at the same time execute it), 'run* mast be touched- This mikes the concept of running a stored program slightly more difficult in version one- Timmy is confident with calling programs by session 14 {see section 3.2.2) and even causes the programs to act on different 'active squares'. 3. .1.2.4 Mode Changing. Timmy was not quite clear about different modes in session 5 (see section 3.2. 1) . He wanted to cause something to happen in the 'play arei ' but was in the 'write' mode; he wondered why touching commands did not result in action. Competence with changing modes was clearly present by session 9. (Section 3.2-2 illus- trates his ability with the concept in session 14-) Linda showed confidence in going between 'write' and 'immediate execution' modes by session 3- (Section 3.3.2.2 contains a description of her repeated invoking of the 'immediate execution' mode to remind herself of the correct sequence of commands for building a garage.) She was introduced to invoking different 'modes' in session 2 (see section 3.2.4). 90 3.3.3 Memory and Data. 3.3.3.1 Data values. a. Primitive Constants- Children were able to use the primitive constants (predefined pictures from the 'store' and characters from the keyboard) in the 'immediate execution" mode after 10 to 20 minutes of exposute to r>AL. (Linda required 15 minutes and Timmy was confident after 20 minutes.) They were able to use the constants to compose pictures in the 'play area'. Linda's first programming attempt consisted solely of pictures from the 'store', indicating thdt the concept is easy. b. Composites. Combining two or more primitive constants to a composite was slightly more difficult. This was also taught in the first session; Timmy composed pictures using 'join' 20 minutes after he wss introduced to it and Linda mastered it in 5 minutes. Even after this, both children frequently used 'droo' when 'join' was needed, but they corrected themselves with no help after seeing 'drop' fail when the 'active square' was occupied. Using composites in programs also proved to be more difficult than using 'drop'. In session 11 91 Tim my wrote i program to draw an "X M . (The program consisted of: slanted right Line, 'pick up', cD, •drop', slanted left line, 'pick up' , cD, •join'.) Linda, in h^r first attempt to write a program which puts a car into a garage, used 'drop* instead of •join'. She needed no help in correctinj her error (see section 3.3.2.2 for a description). 3.3.3.2 Variables, The idp>a that the • play area' consists of squares which can take on different values is easily mastered in the first few minutes of exposure to PAL. As was described earlier, it takes children seven and older no more than 20 minutes to be able to compose complex pictures in the 'play area*. Timmy found it quite difficult to write a program to put primitives into the 'play area 1 . Section 3.2.1 (session 5) shows that John tried to guide Timmy to write a program which would place a picture into the play area, but had to jive up for that session. Tim did write a program in session 5, but one using only •move', a single-step operation- John guided Timmy in writing a program using the 'pick up* and 'drop' sequence in session 2, but Tim did not totally under- stand what he did. After a total of 2 hours, 15 92 minutes programming time, Timmy did succeed in using the 'pick up', 'drop' sequence in a program (session 7). Cutting pictures into the 'play area' is much easier in version 2 since the 'active square' is always located in the 'play area'- Linda did not find it difficult to write proyrams which put pictures into the 'play area'; her tirst programs did that. The above seems to indicate that the concept of variables is not difficult if the implementation makes it easy to use. The children had to initialize variables if they wanted to execute programs which put pictures into the 'play area' more than once. If the 'play area' is not cleared (swept clean with the 'broom') t the second execution of a program will result in the 'drop' commands failing. Timmy frequently noticed (while his program executed for a second time) that he should have previously cleared th^ 'play area'. He did understand the concept and usually stopped the proqran, erased the 'play area' (in version one the -LAB- key had to be pressed to clear the? area), and reran his program. I. in la remenbeLed to clear the 'play area' ibout 80% of the times she retried a program. (In version 2 the 'broom' is pictured on the screen as a reminder.) 93 ^he concept ot variables only taking on 'discrete' values is implicit in the system. Values ot variables consist of primitive values ('store 1 pictures or alphanumeric characters from the keyboard) or combina- tions of them. 3. 3. 3. 3 Stor lge. a. Read Only. Primitive values from the •store' or alphanumeric characters from the keyboard are retrieved from 'read only' storage. Paragraph 3.3.3.1 contains an analy- sis of how the children learned to use these primi- tive values. Predefined or 'book' programs are also located in 'read only' storage. (Version one did not contain 'book' programs.) Linda was introduced to predefined programs in session 6 (see section 3.2.4). She was abls to invoke a predefined program from her program (with little help, see the transcript) 10 minutes after she was first introduced to the concept- b. Read/write. Procedures written by children are stored in 'read/write' memory. Once introduced to the concept, the children found storing their programs very easy. Neither Tiramy nor Linda forgot how to 'wrap' a 94 program (see section 3.2-3, Linda's first introduc- tion to 'wrap 1 ). Writing and editing programs was more difficult and is analyzed in section 3.3.2.2. 3.3. 3. 4 Addressing. The concept of addressing is easy to grasp and was quickly understood by the* children. In PAL locations are referenced simply by touching them - addresses are touch locations. Addressing used in programs will be extensively described in section 3.3.4.2. 3. 3. 4 Programs. 3.3.4.1 Sequence of Instructions. a. Static Sequence. The concept of the static sequence or text of a program is implicitly learned while learning to write a program (see section 3.3.2.2) . b. Dynamic Sequence. The concept of the dynamic sequence or flow of control on a program is grasped when learning to execute programs and to use 'loops*. The 'loop' and 'out' commands cause the dynamic sequence to differ from the static sequence of a program. Thus the concept or dynamic sequence must be understood if •loops' are to be understood (see section 3. 3.4.2»2 for an analysis of the concept of 'loops'). 95 c. Program Pointer. This concept was learned relatively quickly by the children since they actually saw the 'program point- er* point to each successive command as it was executed. In session 14 Timmy seemed to understand the concept (see section 3.2.2). Linda demonstrate! her mastery of the concept in session two (section 3.2.3). d. Syntax. PAL has a very simple syntax; the only restraint is that 'loop' parentheses must match and that 'out' must be inside the 'loop'. Neither Timmy nor Linda ever had unmatched parentheses; they see-ned to visua- lize a 'loop* as one entity. Timmy did reverse the 'loop' parentheses once in session 6. Both children placed tne 'out' outside the 'loop' . (immediately following the 'end loop'). In session 14 (section 3.2.2) Timmy snowed that, even though he put the 'out' outside the 'loop', he did understand its function; he simply made a syntax error. Linda also made this error once in session 4 (section 3.2.4). Both children remembered the rule once the error was pointed out. 96 3.3.4.2 Instructions. 3.3.4.2.1 Primitive Instructions. a. Assignment Statement. The assignment statement is "explicitly" repre- sented by the PAL 'drop' languige command. The •drop' is easy to use in a program (see section 3.2.3, Linda's first programming attempt). It took a longer time for Tiramy to use 'drop* in a program because it was more cumbersome in version one (see Appendix A) . The 'touch store' command assigns a 'store 1 picture to the 'finger box'. This proved to be a very easy command, the first language command Linda used in a program. A tiiird explicit assignment statement is the •pick up' command. Linda used 'pick up' very seldom since it was not very useful in version 2 of PAL. In version 1 Tiuimy had to use 'pick up' to get 'store' pictures into the 'finger box'. He did not have any difficulty understanding the command, he only confused the seguences in which the com- mands had to appear. ♦Erase' (which 'erases' the contents of the 'active square') also proved to be an easy concept. 97 In Timmy 's session 9 Hanna wrote a program designed to put one row of a cheese rboard onto the 'play area' . The program contained an error and placed two solid squares at the end of the row- Hanna then asked Timiny if he could rix the program. After just a few seconds of thought, Timmy added an •erase 1 command to the end of the program! (The program still put two solid squares at the end of the row T but the last command than erased the final square.) Linda did not have an occasion to use 'erase' in her programs. The assignment statement 'join' was more diffi- cult to use chan 'drop'. The children must be very clear about what 'joins' what when using the command. Timmy wrote a program to compose an "X" from slanted right and slanted left lines in session 11. To accomplish his task, ae had to use the 'pick up' and 'drop' commands as well as join Linda used 'join' in session 3 to put lines around a car, i.e. to build a garage. She had to return to the 'immediate execution* mode several times to help remind herself how to use • join' and how to translate it to a program. The 'take away' command was even more difficult 98 for the children since it is even more abstract than 'join'. They did not use it in programs and took longer to master it in the 'immediate execu- tion' mode than all other commands (with the exception of 'move active' which was not useful in the 'immediate execution' mode). The 'move' statements are "implicit'* assignment statement. They assign null to the present 'active square' and its former contents to the new 'active square' . The first program which Timmy wrote on his own consisted solely of 'nove' commands. Linda used 'moves' in session 3 after she hid written programs which 'dropped' pictures onto th3 'play area'. b. Unconditional Transfer of Control. The children found this concept relatively easy, helped by the tact that the program pointer is visible as control is transferred. Timmy demon- strated his familiarity with the concept in session 1U (see section 3.2.2) and Linda in session 6 (section 3.2.5). Section 3.3.4.2.2 contains a further description of the concept of 'loops'. c. Conditional Transfer of Control (the command 'exit' in version 1 and 'out' in version 2). 99 This is not an easy concept, and at first the children used an 'out* with a 'loop' simply because they were following an example. In session 14 (section 3.2.2) Timmy explained that without an •exit' the program would keep failing when it reached the side of the 'play area'. Linda demon- strated her knowledge of the 'out' command in session 6 (section 3.2.5) when she explained why 'out' is needed in the 'loop' she had written. d. Operation. The operations of PAL: 'move', 'drop 1 , 'join', •take away 1 were described in paragraph (a.) of this section. e. Addressi ng. 'Setting 1 an address wis very easy for the children since they only had to touch a position in the 'play area'. The 'active square' would appear around the touched position as the "current ad- dress". Both children learned to recognize addresses by their coordinates as they appear in a program. In the following Timmy shows that he is able to recognize and use addresses in a program (25 minutes into session 6) : J: I have one puzzle, ready? 100 T: Yea. (John calls a previously written program which consists of the commands: bC, 'move up', 'move up', 'move right'; and displays it in the •program space'.) J; OK, here's the puzzle. I want you to tell me if I put a car here (puts a car at position be in the 'play area') and if I put one here (puts a car at aA) and then I push 'run', what will it do? T: I don' t bow. J: Well you have to look at the list. T: This one (points to the cat at a\) will go up one, up one, and then over; and this one right here (points to the one at bC) will go up one, up one and then will go (points to tho right). J: How do you know that they will both go like that instead of just one of them? T: (pauses) 3ach got a car. J: Which will go first? T: (pauses to think) No, T think... T think this one (points to bC). J: Why? T: Cause it's on Cb. J: Is that somewhere else Cb? 101 T: No, it's right up there (points to be, the first command in the program), be. When Linda was writing her program to draw a garage around a car in session 3, sae positioned the garage by watching the coordinates in the program and matching them with commands she was writing. The concept of addressing was much more diffi- cult when the addresses were change] as a byproduct ot the execution of a command (specifically in the •move' and 'move active' commands). Timmy's first solo program consisted only of 'move' commands; he did net explicity think about addressing different positions, only of 'movinj' something (see section 3.2.1, session 5). Timmy found it much more difficult to use the 'move active' command which only moves the 'active square' (the current ad- dress), a much more abstract concept. The 'move active' command was also more difficult for Linda (see section 3.2.5, session 6). 3.3.4.2. 2 Composite Instructions, a. Procedures. In session 5 John wrote a demonstration program which called another procedure. Hanna also wrote a 102 program which calls another in Timmy' s session 9. Both times Timmy did not follow what was happening. He did not seem to be ready or interested in the concept, so it was not pursued till Timmy seemed more confident with writing programs. Five minutes into session 13 Hanna suggested that Timmy write a program to put down a whole row of solid sguares. After 15 minutes, Timmy had written a program which put down four sguares. He then began writing another program which would complete the row. Hanna explained that he could add the first program to the second one to in to do some limited debugging when prompted to jo through her program instruction by instruction. 3.4 Summary and Conclusions. 3. '4. 1 Abstract Concepts are Most Difficult. The most dirficult concepts for the children were ones whose results were not seen immediately. In the 'immedi- ate execution 1 mode the only language? commands which caused any difficulties were the 'move active' commands. They represent an abstract form of addressing whose 107 results depend on a succeeding operation. Direct ad- dressing was easy ior the children since addressing a square is just a matter of touching the desired coordi- nate. Indirect addressing ('move' and 'move active') was moire difficult as the children oft^n lost track of where the current address was and what that location meant in relation to the commands they were executing. The concept of 'loop' (repetition ot a set of com- mands) was much easier to grasp than that of a condition- al exit from a 'loop' ('out' upon failure) . We believe that this is because a conditional exit is influenced by more factors such as the previous conditions and its physical location within the 'loop*. One of our more interesting observations concerns the ability to use commands in the 'immediate execution' and program writing modes. After all commands had been successfully used in the 'immediate execution' mode and the concept of program writing understood, we thought that the knowledge of the commands would be transf errab le to program writing. This did not seem to be the case. When programming was introduced to a child using one or two commands, the child could use only these commands in programs. Each command had to be reintroduced in the program writing mode until about five commands had been 10d so used. At that point the children were able to use the remaining commands in writing programs, even if those commands had only been introduced in the 'immediate execution' moie. When the children had difficulty translating commands from the 'immediate execution* to the prog ramming mode, they found it helpful to remember hov a command was usel 1 ;i the 'immediate execution' 'node. Thus it seemed beneficial that they could use the 'immediate execution' mole to familiarize themselves with the commands before they began to program as well as return to this mode to remind themselves of how the commands worked while they were writing a program. The concept of the system being in different modes is ilso abstract and was difficult foi. tae children to master. They hid trouble realizing which mode they were in and how that would affect their use of different language commands. Often tney didn't remember that stored programs hail to be recalled from the 'immediate execution' mode. If a program name in the 'program store' is touched while the system is in the 'write' mode, the program name will appear in the 'current program' as a subroutine. 109 Editing programs was no problem after the children understood the different modes. They also had little trouble grasping the concept of subroutines, although that was harder than using primitive language commands. The program pointer and the execution sequence of programs were not difficult concepts for the children to understand. In PAL the program pointer is always visible while a program is executing, thus the execution of a program is also an immediately visible event. 1.4.2 Analyzing and Debugging Programs Improved. The children's ability to analyze programs improved greatly over the course of the sessions; they overcame the fear of making mistakes. Their operational knowledge of PAL, however, increased more quickly than their ability to verbalize this knowledge. 1.4.1 Children's Original Ideas Increased. In the first few sessions the children seldom came up with ideas for their programs. They enjoyed programming and were glad when John or Hanna suggested a program topic. This did change somewhat in later sessions. Linda, for example, hid an idea for having a program write "Hello There" onto the 'play area'. When drawing pictures in the 'immediate execution' mode she came up with original ideas such as putting a car into a garage. 110 rt would seem tnat oncre children become T.>re confident with writing projrims they may come up with lore ideas of their own. A classroom environment would also tend to tost or competitive ideas. 111 4 Concluding Thoughts. 4. 1 Recommendations foe Teaching PAL. Wf> believe that children younger than those used in out study can be introduced to PAL. Our recommendations are to begin introducing PAL in a classroom setting in first grade or Kindergardeu and use it as the first in a seguence of mini -languages. In the beginning the children should have very short sessions in which they use the 'immediate execution* mode to draw pictures, got used to computer terminals, learn to use the language commands and expand their imaginations by competing with their peers in drawing pictures. When several children are confident with the •immediate execution' mode, they can be instructed in programming. These children can then help others learn new programming concepts. Finally, PAL could serve as an extra activity for children who have finished their regular class work. 4.2 PAL is a Good Vehicle for Teaching Programming. Programming is taught conventionally at tne University level in one semester for an average of 3 hours per week. Young children seem to learn the concepts of programming more quickly, partially, it seems, because of the features of the PAL system. In PAL the program execution and 112 program pointer are visible- Thus 1the students gain a cleii understanding of what program execution au»ans. The 'immediate execution' mode also seems to be very helpful in introducing programming. Pa pert uses the 'imme- diate execution* concept to get children familiar with commands (21) , Tin above-mentioned ideas could tie carried over to high school and college programming courses. 4.3 Future Considerations. One possible expansion of PAL is the use of audio for the error and other messages. Another possibility is to add commands which request input from the terminal, the introduction of arithmetic algorithms and a random number generator. It could be possible for children to take home cartoon books vhicn they have created in their PAL sessions. I"n analogy to Piaget's studies (particular those of math concepts) , on*' might investigate at what age children can understand various programming concepts. 4. 4 Conclusions. In PAL we believe we have reached our initial goals, namely to develop a simple computer language for children which could be used to teach them how to program as well as study how these children learn to program. Our preliminary tests have shown that interesting observations can be made 113 by analyzing these programming efforts. We feel that similar tests can contribute to our knowledge of the process by which programming is learned *nd help us improve th f » teaching of programming in general. BIBLIOGRAPHY 1 14 (1) Alpert, D. and Bitzer, D. L., "Advances in Computer Based Education", Science, Vol.167 ("larch 1970) , pp. 153 2- 1590. (2) Barker, P. J., "Lock up the Black. dox", Computers in £.liilliii2Ii# Proceedings of the IF IP 2nd World Conference, 1975, pp.971-97'j. ( <) Barr, Avron, and Board, Marian, "An Instructional Inter- ;ic", Sigcse Bulletin, Vj1.3, No. 1 (Feb. preter for 13< 1976) , pp. 125-3 34. (4) Basili, Victor R. and Turner, Albert J. , "Experiences with a Simple Structured Programming Language", Sigcse bulletin, Vol.6, No. 1 (Feb. 1974), pp. 144-147. (5) Bozanson, Willian R. , "Teaching Structured Programming in Fortran with IFTRAN", Si(icse_B ul leti n, vol.7, No.1 (Feb. 1975) , pp. 196- 19 9. (6) Brown, Dean, and E 1-3 ha nna m, Mohammed A., "Computers tor Teaching", Co^iit^r, Vol.6, No. 1 (Jan. 1973), pp. 16-22. (7) Dwyer, Tom, "Solo Works", £^ople^s__Cojpu ter Company* Vol.7, No. 5 (.lay 1974), pp. 11-14. (8) Friedman, Frank L, and Korfman, Elliot B. , "Some Pedagojic Considerations in Teaching Elementary Programming Using Structured Fortrin", S igcse_Bull et in, Vol.3, Mo. 1, (Feb. 1)76), pp. 1-10. (9) Holt, Richard C. and Wortman, David" B. , "A Sequence of Structured Subsets of PL/1", Siqcse Bulletin, Vol- 6, No. 1 (Feb. 1 974) , pp. 121-1 32. (10) Holt, Richard an 1 Wortman, Davii, B., "Subsets of the PL/1 Language", Technical report CSR3-55, Computer Sys- tems Research Group, University of Toronto, May 1975. 115 (11) Learning Research Group, P erson al Dy namic Media, Xerox Palo Alto Research Center, March 1976. (12) Ledgard, Henry F. , "10 Mini Languages", ACI1_Com£utin£ Surveys, Vol.1, No. 3 (Sept- 1971), pp. 115-146. (11) Linder, William H, "COMPUTER TUTOR; From a Student Project to a Self- paced CAI/CMI Course", S i^cseBullet in, Vol.8, No. 3 (Sep. 1976), pp. 57-60. (14) Longworth, Norman, "A Course oa 'Information' for Secon- dary Schools", Computers in_Educa tion , Proceedings of the IFIP 2nd World Conference, 1975, pp. 749-754. (15) Miller, Lance A. and Becker, Curtis A., "Programming in Natural English", IBM Technical Report RC 5137, Thomas J. Watson Research Center, Nov. 15, 1974. (16) Moursund, David and Neill, Mike, "Computer Science for Elementary School Teachers", Si£cse_Bulletin, Vol.0, No. 1 (Feb. 1976) , pp. 24-28. (17) Nanney, T. Ray, "Computer Science: An Essential Course for the Libenl Arts", Sigcse Bulletin, Vol.8, No. 3 1976) , pp. 102-105. (1fl) Newell, Allen and Simon, Herbert, Human Problem Solving, Prentice-Hall Inc, Englewood Cliffs, N.J. 1972. (19) Nicvergelt, Jurg et al. , "ACSES: The Automated Computer Science Education System at the University of Illinois", Report UIUCDCS-R-7C- 81 0, Department of Computer Science, Universtiy of Illinois, Aug. 1976. (20) Papert, Seymour, "Cognitive Development in People and Other Machines", LOGO Working Paper #9, Massachusetts Institute of Technology Artificial Intelligence Labora- tory, April 20, 1971. (21) Papert, Seymour, "A Computer Laboratory for Elementary Shools", LOGO Memo #1, Massachusetts Institute of Techno- logy Artificial Intelligence Laboratory, October, 1971. (22) Papert, Seymour, "Teaching Children Thinking", LOGO Memo #2, Massachusetts Institute of Technology Artificial Intelligence Laboratory, October, 197 1. 116 (21) Paper t, Seymour, "20 Things to do with a Computer", LOGO Mono #3 , flas.sichusGtts Institute of Technology Artificial Intelligence Laboratory, June, 1)71. (24) Perlman, Radii, "TORTIS, Toddler's Own Recursive Inter- preter System", LOGO Memo #9, Massachusetts Institute of Technology Artificial Intelligence Laboratory, March, 197 4. (25) don Santos, Sueli, M. and Millan, Marilia R, "A System for Teaching Pro jr anuning by Means of a Brazilian Mini- Computer", Oojnjjute rs in 2duca_ti^on, Proceedings of the IPIP 2nd World Conference, 1975, pp. 211-215. (26) Sjoerdsma, Ted, "An Interactive Pseudo- Assembler for Introducing Computer Science", Sigcse llilletin Vol.B, Mo.1 (Feb. 1976), pp. 342-349. (27) Smith, Carol and Ricnman, Jon, "Selecting Linguages for Pedagogical Tools in the Computer Science Curriculum", ^iacse_Bullet in, Vol.B, No. 3 (Sept. 1976), pp. 39-47. (28) Soloworks Newsletter #23, Project SOLO, University of Pittsburg, Pa., Nov. 30, 1973. (29) Stern, Randy, "Comments on First Grade LOGO experiments", LOGO Working paper #17, Massachusetts Institute of Tech- nology Artificial Intelligence Laboratory, Miy 14, 1973. (30) Weinberg, Gerald M., The_Psy_cholog_y__of _Comp_u ter_Program- ming. Van Nostrand Reinhold Co., NY, N v , 1971. (31) Woolley, John D. ana filler, Leland R. , "LINUS: A Structured Language for Instructional Use", S igcse_B ulle- tin, Vol.6, No. 1 (Feb. 1974), pp. 1 25-129. 117 APPENDIX A DEVELOPMENT AND DESIGN NOTES. 1, Design f?oals. One of the goals in designing PAL was to create the simplest possible language to avoid influencing the study by the structure of the language. if e strove to implement programming concepts in the easiest possible way, with a minimum of syntactical constrictions. Most sequences of commands should have soma visible effect which can be analyzed and debugged. We wanted to test how the concepts were learned, not how easy or difficult it was to work with idiosyncracies of a language. Since PAL was designed for use by children, we wanted to eliminate as many prerequisites to its use as possible. We wanted children who could not yet read or write to be able to use PAL, to be able to write programs which would be interesting and relevant to them. At the same time, we wanted to make maximum use of the special features of the PLATO system. Tmple.iientat ion of Version 1. The first design decision was to use symbols instead of words to avoid dependence on reading skills. We also decided to use the PLATO screen to simulate a computer. The different parts of the system, the memory, commands, work- space, stored programs, etc. would be visible at all times. Commands would be accessed by simply touching them (taking advantage of the PLATO touch panel) and represented by pictures symbolic of their function (possible because of PLATO's special character design teature). Since the com- mands would be on the screen, the child would be reminded of what is available to him. The system commands were separated from the language commands to indicate differences in function and separated from each other to avoid missed touches. The 'play area 1 was placed in the center of the 118 screen as the center of activity surrounded by a "buffer" to give a margin for inaccurate touches. The 'play area* addresses were to be referenced bv coordinates with the x-coordinates depicted by lower-case letters to distinguish them from the y- coord ina tes represented by capital letters. The memory implementation was decided on after consider- ing a "virtual" type of memory that could be "rolled". We decided against that for compactness of the Language (the amount of space PAL would take up in the rest of the system) and ease of use. T he 'loops' in PAL were chosen for their simplicity: 'loop' brackets surrounding the sequence of instructions to be repeated. Number skills are not necessary to use the 'loops'. The "failing" of commands was chosen as the criteria for 'exiting' a 'loop' since "failure" is easy to recognize and understand in the context of PAL. We decided that the 'exit' command would have to be present in the 'loop' for the program pointer to 'exit* sine? the concept of conditional branching is important. We wanted to implement an 'immediate execution' mode to permit children to familiarize themselves with commands as well as with the idea of "telling the computer «(hat to do". We also considered a "combination mode" which ^oth "immedi- ately executed" a command as it was touched and also stored it in the 'current pLogram* (functioned as a combination of 'write' and 'immediate execution' modes). It was decided that this "mode" was too artificial, since it had no parallels in the world of "real" languages. We also felt that it would prevent the children from gaining familiarity with writing a sequence of commands which do nothing till they are 'run'. 1. Changes Resulting in Version 2. The first testi with children (preliminary tests and the ones with Timmy) indicated areas where PAL should be changed to make the system easier to use and more internally consistent. One thing we noticed was that one square should always be 'active' in the 'play area'. In version 1 the 'active square' could be located in the 'store' or the 'program store'. A position in the 'plav area' or the 'store' could be male the current 'active square' by 119 touching it. We noticed that the only command that could act on an active 'store' picture was 'pick up'- Tn version 2 touching a 'store' picture causes it to he automatically 'picked up*. This eliminated the major syntactical con- straint in PAL, one with which the children had difficulties because they often got the 'pick up', 'drop' sequence wrong. Also in version 2 when an entry in the 'program store' is touched while the system is in the 'immediate execution' mode, it is automatically displayed in the 'program space* and becomes the "current program". In version 1 the 'active squarp' indicator ((lotted box) would appear around the program name (the one touched). To display the program, it had to be 'run'. Touching 'wrap' in version 1 caused the 'current program* to be erased from the * program space*. The system returned with a request to touch -NEXT- if a new program is to be started. This seemed inconsistent and left the children confused as to what they should do if they didn't want to start another program. In version 2 the program remains in the 'program space' and can be added to or edited. 'Write* must be touched if a new program is to be started. (Other system commands can be executed in bot h versions. ) It is also possible to edit a program in version 2. If, instead of typing a name for a new program after touching 'write', a stored program is touched, that program is recalled and can be edited. The screen was also slightly rearranged. In version 1 programs were stored in the same 'store* as the pictures. It was also possible to store composite pictures which we felt was not necessary since a program to create composite pictures could be easily written. We also decided to put stored programs near the language commands to remind the children that they are both used in the same way. Prede- fined programs were added to introduce an additional concept. The tests with children indicated that it was important to erase the 'play area* before re-executing a program. In version 1 the -LAB- key had to be pressed, which the children often forgot to do. Thus we put a 'broom' on the screen near the system commands to ease its use and remind the children to initialize the 'play area' when necessary. 120 Another minor change was to change the name 'exit* to the easier name 'out'. We also decided to make a pointing hand the symbol for the 'immediate execution' (or 'Jo') mode and to have the same symbol represent the program pointer. In version 2 the positions in the 'play area' aro represented by their coordinates in a program, while in version 1 they are represented by a hand pointing at the coordinates- APPENDIX B 121 FORMAL DESCRIPTION OF PAL. (program) ::= (program name> ::- begin loop (statement list> end loop | | (command) I (command) ::= drop J pick up | erase j out | join | take away } move right j move left | move up j move down | move active right | move active left | move active up | move active down J (content) | ::= (capital letter> ::= | (character) l (program name> ::- (letter) | (letter) (letter) | ... | (letter) (letter) (letter) (letter) (character) ::= (lower case letter) | (capital letter) | (digit) (picture) : := house | tree | car | sun \ witch | ,.. (digit) ::= | 1 ] 2 | J j ... | 9 (lower case letter) ::=a|b|c]dj... J z (capital letter) ::=A)3|C|D|... |Z 122 APPENDIX C A BRIEF DESCRIPTION OF THE SESSIONS WITH CHILDREN. T I M M Y Session 1 : 2/14/75, 1 hoar 7 minutes. Timmy learned to use all the language commands in the 'immediate execution' mode with the exception of 'move active' and drew complex pictures in the 'play area'. 2§s.sion_2: 2/21/75, 1 hour. Timmy used the 'immediate execution' mode for the first 10 minutes after which John introduced him to writing programs. With much help Timmy wrote "tim" rfhich put a girl into the 'play area' and moved her right and up. S§_ ssiQU-J : 2/26/75, 40 minutes. John reintroduced the concept of programming to Timmy who was distracted by the presence of his parents. Tim wrote a program consisting of 'moves', still reguiring much prompting.. Session_4: 2/23/75, 55 minutes. Tim attempted to write a program to put down a balloon with no help: 'pick up', aA, 'drop', balloons, several •moves'. John helped Timmy write a program to put a boy into tne 'play area' and Tim added 'move' commands to the program. ^2^ 5ej3sion_5: 3/13/75, 40 minutes. Tiramy wanted to write a program and started one on his own but didn't know how to continue after naming it. After a short explanation by John, Tin my wrote the program 'city' consisting of a 'set play area' followed by 'move' commands. Tim also used 'city' to move other pictures such as a girl with umbrella. Session 6 3/19/75, 30 minutes. John introducel 'loops' and in his first attempt to use them in a program, Tim reversed the 'begin' and 'end loops'- Tim fixed the program which consisted of a 'set play area' and 'moves' inside a 'loop'. Session_7 x _3: 3/20 an 1 3/21/75, 30 minutes each. Timmy practiced using PAL at his school. Hanna only observed and answered questions; Tim worked by himself to gain confidence with PAL. Timmy wrote the programs 'copy' and 'zoom' which put a car in th? 'play area' and moved it. Both programs used 'loops' which con- tained 'exits '. Session_9; 4/25/75, 50 minutes. Timmy wrote on nis own the program "help" which placed a girl onto the 'play area' and moved her. In his initial attempt he put a 'set active square' before the 'move' commands, but corrected his mistake by analyzing the program. Hanna then wrote a program to draw a line of a checkerboard which ended with two solid squares. Tim corrected the problem with no help by adding an 'erase' command to the program. §£§sion_1_0: 7/14/75, ^0 minutes. Hanna reintroduced the concept of program writing 124 because of the long interval between sessions 9 and 10. With very little help Timmy wrote the program •ivy' which placed a tree into the 'play area 1 and moved it up and down (using an infinite 'loop 1 ). Session,! 1 : 7/16/75, 40 minutes. Timmy constructed an "X" in the * immediate execution* mode using the slanted line. He then wrote two programs to compose an "X", the first with help, the second by himself. Ses sio n 12: 7/26/7 5, 1 hour. Timmy executed the program 'ivy' which he wrote in session 10. He then explained what 'loops* do. John suggested writing a program which would cause two cars to crash into each other. With confidence Timmy wrote a program which put two cars down, and caused one to move into the other. A little debugging was required to have the cars dissolve into smoke! §ession_Jl3: 7/27/75, 1 hour 40 minutes. Timmy wanted a program to put a row of solids onto the •play area'. He used the 'pick up', 'drop* sequence and thus had to write two programs, the second calling the first (he had forgotten about 'loops 1 ). Session 14: 8/1/75, 35 minutes. Timmy wanted to make a witch go back and forth (his own idea). After a little trial and error he rediscovered the 'loop' and wrote *rfty' consisting of 'move left' and 'move right' inside a *loop*. He then used the program to move several other picture elements. 125 LINDA Session^: 1/19/77, 1 hour. After 35 minutes Linda was comfortable with all com- mands (including 'move active') in the 'immediate execution* mode. Linda drew a complex composite pic- ture consisting ot a large house composed of line segments and a car in a garage. Session _2: 1/21/77, 1 hour, 15 minutes. The introduction to programming began 15 minutes into the session. Linda's first program with which she needed no help consisted of 10 'store' pictures fol- lowed by: 'drop', dE , house, 'drop' (40 minutes into the session). Five minutes later she wrote a program to place five pictures onto the 'play area'. Session 3: 1/24/77, 1 hour, 20 minutes. Eight minutes into the session Hanna asked Linda to write a program which puts a car into a garage. She was unsure of herself and went back into the 'immediate execution' mole two times to remind herself of which commands to use. 20 minutes later she succeeded. Forty minuter after the start of the session Linda wrote a program to 'move' a picture. It took her 15 minutes to write the program and debug it. Se ssion_4 : 2/7/77, 1 hour, 20 minutes. Hanna suggested a program which puts a boy on a bike into the lowei. left corner of the ' play area' and moves him across to the lower right corner. She succeeded within 20 minutes with little help. Tn 15 more minutes she wrote a program which has a car run into another one and go up in smoke. For the last 15 minutes she composed a sentence in the 'play area'- 126 Session 5: 2/11/77, 1 hour, 30 minutes. Linda drew a picture of a toystore in the •immediate execution' mode. 15 minutes later she wrote a program to have a witch fly over the toystore. After Hanna introduced 'loops', Linda wrote the program which has a boy on a bicyle ride across the 'play area* using a loop. Sessi on f: 2/14/77, 1 hour, 10 minutes. Hanna suggested drawing a row of trees and helped Linda with the use of 'move active'. Linda wrote (with several hints) 'tree': aG, tree, 'drop', bG, 'begin loop', 'drop', 'move active right', 'out', 'end loop'. Hanna showed her how to replace the loop section of the program with a predefined procedure called 'line 1 . Se§sion_7: 2/18/77, 1 hour, 35 minutes. In this session Hanna asked Linda for an idea for a program. Linda wrote a program which put the words "Hello There" onto the 'play area'. She had to use two programs, the first calling the second. Hanna then suggested writiny a program which draws a checkerboard. While her first attempt did produce a program contain- ing a 'loop', she needed some help to complete the project. Sessi on_8 : 2/22/77, 1 hour Since this was the last session, Linda demonstrated PAL and the programs she had written for her parents and sisters. Hanna drew a maze in the 'play area 1 and asked Linda to write a program which would move a girl from the left side to the right side of the maze without counting the number of arrows (to make the program general). Linda wrote a program using 'nested loops' with very few hints. 127 PATRICK Session_J: 4/23/74, 1 hour. Patrick learned to use the language commands in the •immediate execution' mode in the first t€?n minutes- He enjoyed using the 'join' and 'take away' commands most. During the last halt hour Pat was introduced to programming and, with some guidance, wrote a program which moved a car across the 'play area'. §£ssion_2: 5/2/74, 45 minutes. Pat began this session by driwing pictures in the •immediate execution' mode. After 15 minutes he wrote a program which put a sun onto the center of the screen and a man walkinj at the bottom. One half hour into the session Pat was introduced to subroutine calling. With very little help he then wrote a program which put a boy holding an umbrella onto the 'play irea'. This "subroutine" was then called by a progra.ii which moved the boy. J D I Sf25ion_J: 7/23/74, 30 minutes. Jodi learned about the 'pick up', 'drop' sequence and used it to draw a picture. The session was interrupted bv several "crashes" of the PLATO system. Session 9 - 7/24/74, 55 minutes. Jodi familiarized herself with the remaining commands in the 'immediate execution' mode*. She especially enioyed using 'join* and 'take away'. After 25 minutes 128 she was introduced to programming and attempted her first program (with help from Hanna) 15 minutes later. 5e§sion_3: 7/25/74, 50 minutes. Jodi wrote a program which used a 'Loop' to draw a row of houses. After that she wrote a program which placed a girl on a bicycle and moved them across the screen. MIKE Session_J: 8/15/74, 40 minutes. Mike learned to use all commands in the *iamediate execution* mode. He used them to create a composite picture in the •play area 1 . Session 2: 8/16/74, 45 minutes. For the first 10 minutes Mike drew pictures in the 'immediate execution* mode. After that he was intro- duced to programming and wrote a program which put a picture on the 'play area*. Session 3: 8/20/74, 45 minutes. In this session Mike wrote a program which put a car onto one side of the *play area* and then moved it across to the other side. He noticed quickly that he had an infinite loop in his first attempt and corrected it by himself. Mike was very pleased when he succeeded in writing a program which placed a row of suns across the 'play area' since it was his own idea and he did not receive any help with the programming. APPENDIX D SAMPLE PAL PROGRAMS. 1. Hello There (by Linda) 129 hith tf *« 9 4 $■ £ ' « ^s • hi cG T j 6 dG i h H Hello 6 G The Irje eG F e E 6 D gG C 6 B f G A r abode fghij 6 V. r 6 *- -»0D«- i-OO- 33*> n out P hanna i dr lvjrte runptrt ooylflsf \ * tredbarr howl * maze • nam« * 1 irve * hi 2. Checkerboard. 130 6 4- -»0D«- ►00-» CSS* out hanrva I 1 driv rte x>y tre« oarr how hi chl 5t A flsf rnaz< 1 ine 1. Drawing diid Escaping from a 'Maze'. 131 rr\az« ~. &2 V ■ c T 4* HB C C \/ • barr e G j ■ * barr i ■■■■■ hE H ■■ * barr G ■■■■■ f C F ■ ■ 6 E ■■■ ■ & D C B ■ ■ 6 b abcdefghij U V. l> * / 6 -»GD«- -00- ^^ n out Q hanria dr i\3 rt . t run »trt Doy flsf tree * barr how * maze name * 1 l r>e hi 1 -.hi* 132 birr' P P 6 6 6 6 P 6 — JSLn i** 1 ™ rc ? * .i * * T XZB «* f& abcdefghij ^ g ffl ■ n 6 -» n out 9 hanna 1^ driv rte »y tre« Darr how hi chl Ptl fls£ * naze 1 in« 133 • cut _e_^ Q 9 * £ v £ T • -d f • rte r ' t ■ out Q ■ ■■■■■ ) H ■■ rte G ■■■■■ f ' ■ ■ i> * E ■■■ ■ out D ■ ) C ■ ■■■ 1 B ft ■ abode fgh i j \» * W I z ft & *- »-00-» ^ n out Q hanna 1$ dr i\*-te run RstH ooy oarr * oarr maze hi ;hl fls? 134 rt« ' _a_ IE1 C\ & . tJH C xxl lilies* '** * n out 9 hanna I' dnv rte ooy oarr D 5trt hi :hl flsf € -na * z« nam< 1 l rte 4. Flashing "Negative" Sun. 135 !J _ k <&m 9 ■ Ju •it* T 5 "* ■B ■ f** - \/ ■ 6 <0 •6- j i H G F E D C B M r t «-0G-» gj -»0D«- ►O0-» cgS> n i n out Q r hanna || ^ dn v rte ■^ » run strl i 4 flsf tre«parr how * ■naze * name * 1 in« hl 1 abedefghij chl j <> ^ S / • out 136 VITA Hanna Kammerahl Kruczek was bocn in Bremerhaven, West Germany, on February 19, 1948. She immigrated to Chicago in 1957 where she graduated from Nicholas Senn High School in February of 1965 after winning the Westinghouse Science Talent Search- She also received her United States citizenship in that year. Mrs- Kruczek began to study mathematics at the University of Illinois, Chicago Circle where she was elected a member of the honor soroity Alpha Lambda Delta- After completing two years at Chicago Circle, she studied mathematics for two more years at the Universitat Hamburg in West Germany. From September 1969 to January 1970 she attended a course for the training of teachers of Transcendental Meditation in Rishikesh, India. She also worked at subsequent sessions of the same course by simultaneously translating the lectures from English into German. Upon returning to the United States in May of 1970 she taught Transcendental Medita- tion full time until that August. She has continued to teach part time since then. Mrs. Kruczek entered the graduate college of the University of Illinois at Urbana in 1970, receiving her AM in Mathematics in February of 1972. She then began to pursue her doctorate in 137 computer science. During her graduate studies at Illinois, she was elected to associate membership in Sigma Xi, a research society. She was also a member of the Association of Computing Machinery, the Institute of Electronic an Electrical Eugineers and the Society of women Engineers. While in graduate school, Mrs. Kruczek had research assistant ships at the University Administrative Data Processing Center and at the Computer-Based education Research Lib. From 1974 to 1975 she worked as a part-time mathematics instructor at Parkland Community College in Champaign, Illinois. Tn 1975 she married Jerome Anthony Kruczek, moved to Chicago and began working as a computer specialist for the Veterans Administration Data Processing Center, a position she held until December of 1977. 'irs. Kruczek is currently employed as a Senior Education Specialist for Control Data Corporation in Chicago, Illinois, where she provides technical support for the marketing of PLATO to Chicago area companies. BIBLIOGRAPHIC DATA SHEET 1. Report No. UIUCDCS-R-78-910 3. Recipient's Accession No. 4. Title and Subt itlc Analyzing the Learning of Computer Programming Concepts Through the Teaching of PAL 5. Report Date January 197! 7. Author(s) Hanna Kammerahl Kruczek 8- Performing Organization Rept. No - UIUCDCS-R-78-910 9. Performing Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 10. Project/Task/Work Unit No. 11. Contract /Grant No. 12. Sponsoring Organization Name and Address Department of Computer Science University of Illinois at Urbana-Champaign Urbana, Illinois 61801 13. Type of Report & Period Covered Ph.D. Thesis 14. 15. Supplementary Notes 16. Abstracts With the increasing role computers are playing in today's society, it is important that people obtain a general understanding of how computers function. The elementary school is well-suited for introducing computer concepts and the basics of programming. To find the best way of teaching programming to children, the process by which programming is learned should be analyzed; however, little has been done to study the process of learning to program. This thesis describes PAL (Picture Algorithm Language) , a programming language designed for very young children, which we then used as a means of studying this process. Tests in which several children learn to write computer programs are detailed. Also included are observations from these tests as to which concepts are easy and which are difficult to learn. Finally, some suggestions are made for teaching children how to program. 17. Key Words and Document Analysis. 17a. Descriptors Picture Algorithm Language Problem Solving I7b. Identifiers /Opcn-F.nded Terms 7c. COSATI Field/Group 8. Availability Statement Release Unlimited ORM NT | S ., 5 110-70) 19. Security Class (This Report ) UNCLASSIFIED 20. Security ('lass (This- Page UNCLASSIFIED 21. No. of Pages 141 22. USCOMM-DC 40329-P7 1