lowering the barries to programming_a taxonomy of programming environments and languages for novice...

8/12/2019 Lowering the Barries to Programming_A Taxonomy of Programming Environments and Languages for Novice Progr

1/55

Lowering the Barriers to Programming: A Taxonomy of ProgrammingEnvironments and Languages for Novice Programmers

Caitlin Kelleher and Randy Pausch

Carnegie Mellon University

Since the early 1960s, researchers have built a number of programming languages andenvironments with the intention of making programming accessible to a larger numberof people. This article presents a taxonomy of languages and environments designed tomake programming more accessible to novice programmers of all ages. The systems areorganized by their primary goal, either to teach programming or to use programming toempower their users, and then, by each systems authors approach, to making learning to program easier for novice programmers. The article explains all categories in thetaxonomy, provides a brief description of the systems in each category, and suggests

some avenues for future work in novice programming environments and languages.Categories and Subject Descriptors: H.5.2 [ Information Interfaces andPresentation ]: User Interfaces User-centered design; Interaction styles; Theory andmethods ; K.3 [Computing Milieux ]: Computers and Education

General Terms: Design, Languages, Human Factors

Additional Key Words and Phrases: Human-computer interaction, computer Scienceeducation, literacy, learning, problem solving

1. INTRODUCTION

Learning to program can be very difcultfor beginners of all ages. In addition tothe challenges of learning to form struc-tured solutions to problems and under-standing how programs are executed, be-ginning programmers also have to learn arigidsyntax and rigid commands that mayhave seemingly arbitrary or perhaps con-fusing names. Tackling all of these chal-lenges simultaneously can be overwhelm-ing and often discouraging for beginning

This work was supported by a National Science Foundation graduate fellowship and grants from DARPA,NSF, NASA, and ONR. Authors address: Department of Computer Science, Carnegie Mellon University, 5000 Forbes Ave.,

Pittsburgh, PA 15213; email: [email protected] to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for prot or direct commercial advantage andthat copies show this notice on the rst page or initial screen of a display along with the full citation.Copyrights for components of this work owned by others than ACM must be honored. Abstracting withcredit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use anycomponent of this work in other works requires prior specic permission and/or a fee. Permissions may berequested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: + 1 (212)869-0481, or [email protected] 2005 ACM 0360-0300/05/0600-0083 $5.00

programmers. Since the early 1960s, re-searchers have built a numberof program-ming languages and environments withthe intention of making programming ac-cessible to a larger number of people. Thisarticle presents a taxonomy of these lan-guages and environments and discussesthe challenges they address.

For the purposes of this article, we de-ne programming as the act of assem-bling a set of symbols representing com-putational actions. Using these symbols,users can express their intentions to the

ACM Computing Surveys, Vol. 37, No. 2, June 2005, pp. 83137.


2/55

84 C. Kelleher and R. Pausch

computer and, given a set of symbols, auser who understands the symbols canpredict the behavior of the computer. Thisdenition excludes many of the Program-ming by Demonstration systems [Cypher1993] where the computer observes theusers actions and uses internal heuris-tics to generate a program for the user. Inthese systems, the user cannot accuratelypredict what program will be produced.

In this article,we describe thehigh-levelorganization of our taxonomy, present thetaxonomy, and briey describe all of thecategories and systems within those cat-egories. We then present two additionaltables: a table of the most inuentialsystems and a system comparison table.The system comparison table comparesall systems in our taxonomy based on1) what programming constructs they sup-port, and 2) their approaches to making programming more accessible to noviceprogrammers. Finally, we summarize theapproaches and discuss some possibleavenues for future work in this area. Appendix A contains a complete list of thesystems included in thetaxonomy, their lo-cations within the taxonomy, and pointersto associated Web pages.

2. TAXONOMYIn creating a programming environmentfor novices, one of the rst questionsthat must be answered is why novicesneed to program. There are a variety of possible motivations for learning to pro-gram: to pursue programming as a ca-reer path, to learn how to solve problemsin a structured and logical way, to buildsoftware customized for personal use, toexplore ideas in other subject areas, andso on. The systems in this taxonomy (seeFigure 1) fall into two large groups: sys-tems that attempt to teach programming for its own sake and those that attempt tosupport theuseof programming in pursuitof another goal such as teaching cognitivemodeling to psychology students. Becausethese two goals place very different con-straints on systems, the taxonomy is or-ganized rst by the system goals, eitherteaching or using programming, and, sec-

ond, by the primary aspect of program-ming that the system attempts to simplify.Each systemappears in thetaxonomy onlyonce. However, many of the systems in thetaxonomy have builton the ideas of earliersystems. Consequently, a system that wasinuenced by natural language program-ming may not be classied with other nat-ural language systems if supporting nat-ural language programming was not thesystems primary contribution.

3. TEACHING SYSTEMS

These systems were designed with thegoal of helping people learn to program.Most of the systems in this category are (orinclude) simple programming tools thatprovide novice programmers with expo-sure to some of the fundamental aspectsof the programming process. After gain-ing experience with a teaching system,students are expected to move to moregeneral-purpose, commercially availablelanguages. A few systems attempt to provide support in learning a more generallanguage from the start. Because studentsinteracting with teaching systems are ex-pected to transition to general-purposelanguages, many teaching systems are in-tentionally similar to general-purpose lan-guages. For example, knowing that a stu-dent will eventually have to do for loopsin a Java-style, the designers of teach-ing languages are less likely to intro-duce a different style of looping. Becausegeneral-purpose languages are not alwaysdesigned with beginners in mind, the sys-tems in this category are juggling two pos-sibly conicting goals: making it easierfor beginners to get started programming,and giving students a background thatmakes it easy for them to transition fromthe teaching system to a general-purposelanguage.

The teaching systems focus on severalareas that can be difcult for novice pro-grammers. The majority of the systemsin this category address the mechanicsof programming: both expressing inten-tions to the computer and understand-ing the actions of the computer [Norman1986]. Other systems attempt to place

ACM Computing Surveys, Vol. 37, No. 2, June 2005.


3/55

Lowering the Barriers to Programming 85

Fig. 1 . Novice programming systems and languages taxonomy.



4/55


Fig. 1 . (Continued ).

programming in a context that is acces-sible and motivating to a wider audi-ence of people either by providing concretereasons for programming or by support-ing novice programmers working togetherand learning from one another.

3.1. Mechanics of Programming

The systems in this category are designedaround the hypothesis that the primarybarrier in learning to program lies in themechanics of writing programs. To suc-cessfully write a program, users must un-derstand several topics: how to express in-

structions to the computer (e.g., syntax),how to organize these instructions (e.g.,programming style), and how the com-puter executes these statements. Systemsin this category attempt to make it easierfor beginners to learn one of these three

skills.

3.1.1. Expressing Programs. In mostgeneral-purpose languages, users createprograms by typing sentences into a texteditor. Beginning programmers oftenhave trouble translating their intentionsinto syntactically correct statements that



5/55


the computer can understand. The sys-tems in this category explore two possibleavenues for making this process easierfor beginning programmers: improve thelanguage so that beginners can moreeasily learn it or nd alternate waysfor be g inners to communicate theirinstructions to the computer.

Simplify Entering Code. Manygeneral-purpose languages have been in-uenced by the need for sufcient power totackle arbitrary programming tasks and adesire to make the programming languageeasier to implement, making the result-ing languages unnecessarily difcult forbeginning programmers. The systems inthis category examine three approaches tomaking languages more approachable forbeginning programmers: 1) simplifying the language, 2) tailoring the languagefor a specic, small domain of program-ming problems, and 3) preventing syntaxerrors.

(1) Simplify the Language. General-purpose languages typically include alarge variety of syntactic elements thatcan be particularly difcult for beginnersbecause these syntactic elements donthave an obvious meaning. The languagesin this category use a few simple observations to decrease the number of po-tentially confusing syntactic elements en-countered by beginning users while trying to maintain as much similarity as possibleto general-purpose languages. General-purpose languages often contain unneces-sary syntax, use commands whose namesare unfamiliar or have different mean-ings in the programming language thanin standard English, have inconsistentuses for syntactic elements, or includefeatures inappropriate for beginning pro-grammers. Using these observations, it ispossible to make a language syntacticallyeasier for beginners to handle withoutfundamentally changing the common con-trol structures found in general-purposelanguages. Consequently, when a studentmoves from one of these languages to ageneral-purpose language, they should beable to transfer their knowledge from theteaching language.

Fig. 2 . A for loop to compute the sum of the numbersfrom 1 to 10 written in Fortran and Basic.

BASIC: D ARTMOUTH COLLEGE , 1963[Kurtz 1981]. Basic was designed toteach Dartmouths non-science studentsabout computing through programming.Fortran and Algol, the commonly usedlanguages at the time, were both largeand complex. Kemeny and Kurtz believedthat the students would balk at theseemingly pointless detail [Kurtz 1981]. After considering using subsets of Fortranor Algol, Kemeny and Kurtz agreed theywould have to create their own lan-guage. The Basic (Beginners All-purposeSymbolic Instruction Code) languagewas designed to support a small set of instructions and remove unnecessarysyntax. The environment was designed tohave rapid turnaround time and sacricecomputer time for user time (in 1963, thecomputer science community was arguing against high-level languages because thecompilation time was seemingly wastedcomputation).

Statements in Basic consist of threeparts: a line number (e.g., 110), an oper-ator (e.g., LET), and an operand (e.g., S =S + 1). All commands begin with an En-glish word to make the language easierfor the novice; the designers believed thatLET S = S + I would be easier for stu-dents to understand than S = S + I.Figure 2 shows a simple summation loopin both Fortranand Basic. While thestate-ments have a similar structure, the Ba-sic program uses language more suitablefor a novice, removes elements like labels(e.g., 30) that require a more detailed un-derstanding of the program counter, anddoes not depend on spacing for syntacticmeaning.

SP/ K : UNIVERSITY OF TORONTO , 1977 [Holtetal. 1977]. SP/k is a subsetof PL/1 chosenfor teaching introductory programming.The features of the SP/k language werechosen to remove redundant constructs,inconsistencies in the language that go



6/55


against students intuitions (in PL/1, theexpression 25 + 1/3 evaluates to 5.3333),constructs that are easily misused suchas pointers, andconstructs like concurrentprogramming that are suited for advancedprogrammers. The difculty of compiling constructs was also considered. The re-sult of pruning was a simpler languagefor introductory programming that bothstudents and teachers generally preferredover Fortran. Theauthors also provided anorder for introducing programming con-structs as a sequence of subsets of SP/k.SP/1 introduces expressions and output.By SP/8, students have learned all of SP/k.By introducing things gradually, studentscan master a small piece of the languageat a time, allowing them to devote moretime to problem solving than memorizing the features of the language.

TURING : UNIVERSITY OF TORONTO , 1988[Holt and Cordy 1988]. The Turing lan-guage was developed as both a general-purpose and instructional language forthe Computer Science Department atthe University of Toronto. Consequently,while the designers intended that Turing be used in teaching programming, thelanguage design was inuenced by a de-sire to help expert programmers by in-cluding powerful programming features.The Turing language contains all the fea-tures of Pascal (see Section 3.1.2) andadds dynamic arrays, modules, and vary-ing length strings. In addition, Turing simplies the syntax by removing the re-quirement for headers declaring the nameof the program and semicolons at the endof each statement.

BLUE L ANGUAGE : UNIVERSITY OF MONASH ,1996 [Kolling and Rosenberg 1996]. Blueis an object-oriented language designed tobe taught as a rst language. After using Blue for a year, students are expected tomove to an industrial language such asC++. The designers of the language usedfour criteria in creating Blue: there shouldbe only one way to do everything; thelanguage should cleanly reect the the-oretical model; the language should bereadable so students can learn by reading examples; and the language should explic-itly support software engineering mecha-

nisms like pre- and post-conditions. TheBlue language is a pure object-orientedlanguage that supports single inheritance,garbage collection, and strong static typ-ing. Classes are dened in single les witha structure that clearly reects which rou-tines others can call and which routinesare internal to the class by placing rou-tines in separate internal and interfaceareas within the le. Routine denitionsinclude explicit pre- and post-conditions.Blue provides a single loop structure thatconsists of a set of statements followed bya list of conditions that should cause theloop to exit, which can be used to createloops that function like traditional for andwhile loops. Each loop exit condition caninclude statements to execute if the loopexits on that particular condition. The de-signers of the language also created anenvironment for beginning programmersthat will be discussed separately.

JJ: C ALIFORNIA STATE UNIVERSITY ANDC ALIFORNIA INSTITUTE OF TECHNOLOGY , 1998[Motil and Epstein 1998]. Full fea-tured, general-purpose languages forcebeginning students to focus on the syntaxrather than the problem they are trying to solve in writing a program. JJ (JuniorJava) is a language designed to removemuch of the syntactic complexity in or-der to allow students to focus on the con-cepts of programming. It removes much of the punctuation such as braces and semi-colons and has only one way to do any-thing; there is one integer type, one wayto create a comment, and so on. The lan-guage also provides an easy migration toJava after the rst half of the semester.Students can either do this by hand or theenvironment can convert their JJ code toJava automatically. Figure 3 shows an ex-ample of computing weekly pay in JJ andthe equivalent code in Java. Due to lack of adoption, the designers of JJ have movedtowards improving students classroomexperiences with Java by providing bet-ter compilation error messages and al-lowing students to program over theWeb.

GRAIL: M ONASH UNIVERSITY , 1999[McIver 1999, 2001]. Grail was developedin response to the hypothesis that it is the



7/55


Fig. 3 . A short segment of code to compute a workers weekly pay shown in both JJ andJava. Note the line-by-line correspondence.

Fig. 4 . This is an If-statement template as it appeared in the Cornell Pro-gram Synthesizer. The words condition and statement are placeholdersthe user replaces with a condition (such as k < 1) or a programming state-ment, respectively.

unfamiliarity of hieroglyphics (i.e. thelanguage syntax) and the sheer com-plexity of the full theory that are theprimary stumbling blocks for the novice[McIver 2001]. Three guiding principlesgoverned the design of GRAIL: maintaina consistent syntax; use terms that noviceprogrammers are likely to be familiarwith and avoid standard programming terms that have different meanings in En-glish; and include only constructs that arefairly simple and have a single, obvioussyntax [McIver 2001]. These guidelinesled to an imperative language with manysmall differences from commonly usedteaching languages such as Pascal (seeSection 3.1.2). The list of changes is toolong to reproduce here but we list a fewto give the reader a feel for the kinds of changes made for the Grail language.Rather than using * for multiplication,Grail uses because it is a symbolthat novice programmers will understandfrom mathematics classes. Values areassigned using an arrow indicating wherethe answer will be placed since a = bis ambiguous. McIver removed pointersbecause they are difcult to use correctly;using pointers, it is very easy for begin-ners to create problems they cannot easilyunderstand or explain. The full details

of the Grail language can be found inMcIvers thesis.

(2) Prevent Syntax Errors. One of thelargest and most frustrating challengesfornoviceprogrammers is syntax. Thesys-tems in this category are programming environments for existing languages suchas Pascal and Fortran that are designedto prevent users from making syntax er-rors using the hierarchical structure of programs.

CORNELL P ROGRAM S YNTHESIZER : CORNELLUNIVERSITY , 1981 [Reps and Teitelbaum1989; Teitelbaum and Reps 1981]. TheCornell Program Synthesizer was a struc-ture editor designed to prevent studentsfrom making syntax errors. Using the syn-thesizer, students constructed programsby adding predened templates for state-ments in a programming language (seeFigure 4). A template often containsplaceholders for statements, conditions, orphrases. These are essentially blanks forthe user to ll in. To prevent syntax errors,the system presented only templates thatwould be syntactically valid at the cur-sors current location. Students could usethe arrow keys to move to the next orprevious place in their program wherethey could add, remove, or edit a tem-plate based on the abstract syntax tree.



8/55


While the designers of the Cornell Pro-gram Synthesizer originally wanted to re-quire programs to always be syntactically valid, they found this requirement madecertain kinds of edits, such as changing a variable name, extremely difcult. In re-sponse, they changed the Cornell ProgramSynthesizer to allow syntactically invalidstatements buthighlight them to draw theusers attention.

GNOME: C ARNEGIE MELLON UNIVERSITY ,1984 [Miller et al. 1994]. The Gnomeenvironments were an attempt to make astructure editor for novice programmersthat was more versatile than the CornellProgram Synthesizer. Gnome displayedprograms hierarchically, encouraging stu-dents to think about programs as hierar-chical collections of procedures. Studentsnavigated through their programs using arrow keys that corresponded to move-ments in the abstract syntax tree; Gnomedisplayed program segments in the famil-iar textual form. When the programmerattempted to move thecursorafter an edit,Gnome analyzed the program, reportedany syntax errors, and prevented theprogrammer from moving on until theprogram was syntactically correct. Theprogrammer could also request an analy-sis of the program at any time. While thisenvironment prevented syntax errors, itactually required students to think moreabout syntax than they previously had:they needed to have a mental model of thesyntax tree to navigate through the sys-tem; the abstract syntax representationsometimes differed from the textual repre-sentation (particularly withmathematicalequations); and the requirement for syn-tactic correctness sometimes preventedstudents from making desired changes inthe program because the fastest route toa correct program required intermediatestages that were not syntactically correct.Gnome environments were created forKarel the Robot, Pascal, Fortran, andLisp.

M ACGNOME : C ARNEGIE MELLON UNIVER -SITY , 1986 [Miller et al. 1994]. TheMacGnome project attempted to cleanlyintegrate the structure-editing capabili-ties of Gnome with the text-editing model

present in traditional programming ed-itors. The Gnome project demonstratedthat students have difculty navigating in the abstract syntax tree. To allevi-ate this problem, MacGnome allowed stu-dents to navigate using point and clickwith a mouse. In Gnome, students of-ten had trouble modifying code because of the requirement to maintain syntactic cor-rectness. Rather than requiring syntacticcorrectness at all times, the MacGnomeproject editors converted the syntax treeinto a textual representation to allow edit-ing without syntactic constraints. Oncethe user nished editing, it converted themodied code back to tree representationusing an incremental parser. By allow-ing students to edit code textually, theMacGnome environment could not prevent syntax errors. However, MacGnomedetected and reported all syntax errorsas soon as the code was parsed, allowing students to correct them before moving toother sections of the program. The noviceprogramming environmentsproduced as aresult of the MacGnome project are calledGenies.

Find Alternatives to Typing Programs. De-spite the attempts to make programming languages simpler and more understand-able, many novices still struggle with syn-tax, for example, remembering the namesof commands, the order of parameters,whether or not they are supposed to useparentheses or braces, and so on. An-other large set of systems are designedaround the belief that to enable novicesto understand what programming reallyis, we need to bypass the syntax problemsaltogether. The systems in this categoryrepresent three major approaches to by-passing syntax: creating objects that rep-resent code that can be moved around andcombined in different ways, using actionsof the user within the interface to deneprograms, and providing multiple mecha-nisms for creating programs.

(1) Construct Programs Using Graph-ical or Physical Objects. The systems inthis group use graphical or physical objects to represent elements of a program



9/55


such as commands, control structures, or variables. These objects can be movedaround and combined in different ways toform programs. Novice programmers needonly to recognize the names of commandsand the syntax of the statements is en-coded in the shapes of the objects, prevent-ing them from creating syntactically incor-rect statements.

TORTIS S LOT M ACHINE : MIT A RTIFICIALINTELLIGENCE L AB, 1976 [Perlman 1976].The Tortis Slot Machine is a physicalinterface that allows young children tocontrol a robotic turtle inspired by theLogo turtle (see Section 4.1.2). Since therobotic turtle is very slow, a simulated on-screen graphical version is provided formore advanced students. The Slot Ma-chine consists of a set of command cardsand rectangular boxes (called rows) thatrepresent procedures and contain slots forcommand cards.Children created SlotMa-chine programs by placing cards in slotsof the rows and having the turtle exe-cute the cards in order. The Slot Machineprovided several uniquely colored rows sothat children could create different proce-dures in each row. Children could call theirprocedures using a colored card that in-structed the Slot Machine to execute thecards in the row corresponding to thatcolor.

P ICT: UNIVERSITY OF W ASHINGTON , 1984[Glinert and Tanimoto 1984]. Pict allowsnovice programmers to create simple pro-grams by connecting graphical icons thatrepresent commands. Pict allows users tobuild programs that do simple numericcalculation using the addition and sub-traction of integers, variable assignment,and Boolean tests. To create a program,users select relevant icons (commands)from a menu screen area and positionthem on a workspace screen area using a joystick. After positioning icons on theworkspace, the user can connect a pairof icons together by clicking on the twoendpoints in turn. When a user runs aprogram, Pict animates the execution of the program by moving a white box along the execution path of the program. Userscan run a Pict program at any point inits development. If the running program

reaches a point where its behavior hasnot been specied, it will halt and notifythe user that additional programming isnecessary.

PLAY : UNIVERSITY OF W ASHINGTON , 1986[Tanimoto and Runyan 1986]. Play is asystem designed to allow preliterate chil-dren to create graphical plays using aniconic language. Stories consist of a lin-ear sequence of actions that is displayedat the top of the screen, above the storysstage, as a sequence of icons similar toa comic strip. The character, what thecharacter should do, and one additionalpiece of informationtypically a directionto moveall selected from menus, spec-ify each action in the story. Play also provides a character editor where childrencan draw additional images of their char-acters and compose those images to cre-ate new animations. Play does not allowchildren to use more complicated controlstructures such as loops and conditionalsor dene procedures.

SHOW AND TELL : W ASHINGTON UNIVERSITY AND BELL L ABS, 1990 [Kimura et al. 1990].Show and Tell is a dataow-based visuallanguage designed forchildren.A programin Show and Tell consists of a series of con-nected boxes. A box can represent a valueor an operation on values. The programincludes boxes that represent basic arith-metic functions, system input and out-put, and some special purpose boxes thatplay sounds or act as timers, and so forth.Children can build procedures by draw-ing their own icon for a box and dening what should happen in the procedure us-ing other boxes. Procedures can call them-selves. Because boxes are not permittedto form cycles or loops, users cannot con-struct for and while loops. However, ShowandTellprovides an iterationbox that provides bounded iteration, in other words,the function will continue repeating un-til a boundary value is reached. If twoconnecting boxes contain different values(e.g., 2 and 3), they and their parent boxare marked inconsistent and become invisible to the other boxes. By checking forconsistency and inconsistency in particu-lar boxes, children can represent simpleBoolean conditions.



10/55


Fig. 5 . A view of the My Magic Castle courtyard. The user is creating the rule Nickyshould dance when it meets the horse.

M Y M AKE BELIEVE C ASTLE [LOGO COM-PUTER S YSTEMS INCORPORATED 1995]. MyMake Believe Castle is a play programfor children ages 47 that contains activ-ities designed to help develop childrensproblem-solving abilities, critical think-ing, sequential planning, and memory.The castle consists of a number of rooms,each containing an activity. In the court-yard of the castle, characters such as thedragon, prince, princess, and horse movearound. When the user clicks on themwith a particular tool, they will dance, slipon banana peels, do somersaults, and soforth. After children have played in thecourtyard space, they are introduced to a very simple, rule-based programming sys-tem. Editors for each character allow chil-dren to specify which action a charactershould take when it meets another spe-cic character. A typical rule might beNicky dances when it meets the horse(see Figure 5). Rules are specied graph-ically; children select the action using icons and the character that should trig-ger the action by selecting a picture of thatcharacter.

THINKIN THINGS COLLECTION 3- H ALF TIME[EDMARK CORPORATION 1995] Half Time isone of the activities in the computer gameThinkin Things Collection 3. The activityrevolves around creating a half-time show(see Figure 6). Users can select charactersfrom the top left and drag them onto theeld; each half-time show can have a to-tal of thirty characters of three types (suchas tuba, percussion, and trumpet players). At the bottom of the screen, there is aline for each of the three types of char-acters in which users can drop instruc-tions for how they want them to perform.The available instructions are similar tothose of the Logo (see Section 4.1.2) turtle:move forward, turn left and right, turnrandomly, pause, pen down and up, andso on. Programs are created by dragging the icons for instructions (shown below thefootball eld) into the lines fora particulartype of character. Counted loops are sup-ported but no other block statements areavailable.

LOGOBLOCKS : MIT MEDIA L AB, 1996[Begel 1996]. LogoBlocks is a graphi-cal programming language designed for



11/55


Fig. 6 . A screenshot of Half-Time from Thinkin Things Collection 3.

the Programmable Brick, a precursor tothe commercial Lego Mindstorms system[1998], developed by the MIT Media Lab(see Figure 7). In LogoBlocks, labeled,graphical shapes represent commands inBrickLogo, an extension of Logo (see Sec-tion 4.1.2) that provides commands forthe Programmable Brick. These graphicalblocks can be dragged off a tool palette onthe side of the screen to a main work areawhere they can be placed next to otherblocks to form programs. Like many vi-sual programming environments, changesto programs may require the user to moveexisting statements to make room for newones. The parts in the palette can take sev-eral forms, for example, a block marked Aspecies the motor A as the recipient of commands following it, but, by clicking onthe A block, the user can turn it into a Bor an ABblock. Commands andcondition-als also have multiple forms; the blocks inthe tool palette represent kinds of objectsrather than all available objects. Com-mands and conditionals requiring argu-ments have shapes with cutouts for plac-

ing the arguments so that it is clear boththat the command requires an argument,and the type of the argument which isspecied by the shapes of blocks that willt into the cutout. LogoBlocks includessupport for procedures; users can attachcommands to purple procedure blocks andname their procedures.

PET P ARK BLOCKS : MIT MEDIA L AB,1998 [Cheng 1998]. Pet Park Blocks isa graphical programming language, in-spired by LogoBlocks, which was devel-oped for the Pet Park collaborative environment (described in Section 3.2.1). Animations are represented by notchedsquares that t together. Conditionals arerepresented by squares with half ovalcutouts where conditions can be added.Like LogoBlocks, programming constructsare kept in a palette from which userscan drag them onto an active area.Pet Park Blocks provides a button thatallows users to see their Blocks pro-gram as a textual program. This allowsusers to gradually transition to text-basedprogramming.



12/55


Fig. 7 . A LogoBlocks program that waits for a light sensor to get a reading of less than 10 andthen turns motor A on for 20 seconds.

DRAPE : UNIVERSITEIT UTRECHT , 2000[Overmars 2000]. Drape is a programming environment that allowsusers to draw pic-tures (see Figure 8).There is a collection of pictorial icons on the left side of the inter-face that represent different commandssimilar to the Logo (see Section 4.1.2) tur-tle commandspen up, pen down, movein different directions, move in shapes,and so on. The icons can be dragged tothe lines at the bottom of the screen thatrepresent the program; commands areexecuted from left to right. There areextra lines associated with their ownicons that can serve as procedure calls.The system does have support for somepredened blocks such as repeat 10 times(shown as 10). However, to apply therepeat 10 to more than a single object, thesequence needs to be enclosed in bracketswhich introduces the possibility for syntaxerrors in the form of mismatched braces.

ELECTRONIC BLOCKS : UNIVERSITY OFQUEENSLAND , 2000 [Wyeth and Purchase2000]. Unlike the graphical objects usedto construct programs in other systems,

Electronic Blocks are physical Lego blocksdesigned to allow young children (ages38) to create Lego forms with interest-ing behaviors (see Figure 9). Preschoolchildren can build block towers that ashwhen they talk or cars that move whena ashlight shines on them. Three typesof blocks are provided: sensor blocksthat can detect light, sound, and touch;logic blocks that can compute AND, NOT,TOGGLE, and DELAY; and action blocksthat can produce light, sound, and motion.The syntax of Electronic Blocks is verysimple; the only requirements are thateach stack includes a sensor block andan action block and that the action blockbe at the bottom of that stack. Actionblocks are smooth on the bottom so theycannot be placed on top of other blocktypes.

A LICE 2: C ARNEGIE MELLON UNIVERSITY [2003]. Alice is a programming sys-tem for building 3D virtual worlds, typi-cally short animated movies or games. In Alice, users construct programs by drag-ging and dropping graphical command



13/55


Fig. 8 . DRAPE drawing and programming environment allows children to draw pictures.

tiles and selecting parameters from drop-down menus. Figure 10 shows an Alicescreen as a user creates a simple ani-mation. To add to the current animation,the user drags a graphical tile, labeledwith the name of the desired action, fromthe selected objects methods, in this casethe IceSkaters methods displayed in thelower-left panel. When the user drops thetile, the system automatically cascadesto menus that allow the user to select valid parameters for the chosen method.In Figure 10, the user has just draggedand dropped IceSkater turn from thepaneland has chosen to have IceSkater turnright one full turn. Students can also addstandard programming control structuressuch as if-statements and loops by drag-ging if and loop tiles from the top bar.Where many no-typing programming sys-tems present users with only a few of thestandard programming constructs, Aliceallows students to gain experiencewith allof the standard constructs taught in in-troductory programming classes withoutmaking syntax errors

M AGIC FOREST : LOGOTRON [2002]. MagicForest (see Figure11) allows children agesfour and up to play with, change, and cre-ate Activities that consist of 2D-spritesthat can move around, change appear-ance, and react to simple events. Eachsprite can be given a set of Rules (rep-resented by a scroll containing stones),a combination of an event and a list of things that should happen, in order, af-ter that event occurs. Both events andactions are represented by graphicalstones that can be identied by their icons,making it possible for children to learnhow to use Magic Forest without needing to know how to read. Magic Forest sup-ports a variety of events, such as mouse-based events, events based on the relativepositions of objects, and message-passing events. Actions might change thedirectionor speed of an object, the appearance of an object, send a message, play sounds,or update the score. To add a new ruleto a sprite, a child selects an event froma scrolling list of available event stones,clicks on it to pick it up, and then drops



14/55


Fig. 9 . Electronic Blocks: the three sensing blocks are pictured on the

left, the logic blocks in the middle, and the action blocks on the right.

Fig. 10 . Building my rst animation in Alice. In my rst animation , IceSkater moves forwardwhile she raises her leg. Then, if IceSkater is close to a hole in the ice, she falls through it.

it onto a scroll associated with that sprite.The child can then attach action tiles tothe end of the event. As in Logoblocks,some tiles can have multiple forms; asingle tile can be used to increase thespeed, heading, or size of an object. Chil-dren can click on a tile to change which

form it takes (increase speed, heading, orsize).

(2) Create Programs Using Interface Actions. The systems in the previous cat-egory used the metaphor of constructing programs by arranging physical or graph-ical objects, while the systems in this



15/55


Fig. 11 . Magic Forest allows children to control the actions and appearances of 2D-characters. Thisactivity has ve characters: a witch, a cat, and three spiders. The witch has two rules controlling her behavior. The top one (blue tile on a scroll) allows the user to move the witch around the scene.The second says that when the witch touches another object, she should make a sound (e.g., laugh).The witch also has an empty scroll to which the user can add new behaviors by selecting events andactions from the brown window at the top of the screen and placing them together on her scroll.

category use interface actions (such asbutton presses or motion through space)or sequences of interface actions as thebuilding blocks of programs. Since mostof these interfaces are on physical objects,the interfaces either tend to provide a lim-ited number of commands or require theuser to perform interface actions (such aspressing buttons) in a specic sequence,introducing thepossibility forsequencesof actions that do not correspond to valid pro-gram instructions.

TORTISB UTTON BOX : MIT A RTIFICIALINTELLIGENCE L AB, 1976 [Perlman 1976].The Tortis Button Box is a physical inter-face that allows young children to controla robotic turtle inspired by the Logo tur-tle. The Button Box provides a set of fourboxes for controlling the turtle that can begiven to a child gradually. The rst boxprovides buttons that move and turn the

turtle, pick up or put down the pen, turna light on and off, and sound a horn. Thesecond box adds numbers so that a childcan repeat a command multiple times bypressing a number, followed by a com-mand. The third box adds a program areawhere children can get the turtle to re-member commands and then play backremembered commands. Thefourthand-nal box creates four procedures (named bycolors) that can call each other. The buttonbox system did not allow students to editprograms after creating them, making thegradual modication of programs difcult.

ROAMER : V ALIANT TECHNOLOGIES , 1989[Catlin 1989]. Roamer is a programmable,mobile robot that has capabilities similarto those of the Logo turtle: the Roamercan move forward and back, turn left andright, wait, and make sounds. Programsare entered using a set of buttons with



16/55


icons for the commands and a number padto indicate how far to move or turn andwhat sound to play. Buttons are also provided for creating procedures and repeat-ing statements. The Roamer can remem-ber up to59 instructions ineither the mainprogram (the GO program) or numberedprocedures that can be called from the GOprogram or each other. An expansion setallows users to add on sensors, two-stateoutputs, and a stepper motor, allowing agreater variety of programs.

LEGO SHEETS : UNIVERSITY OF COLORADO ,1995 [Gindling et al. 1995]. LegoSheets at-tempts to provide a gentle introduction toprogramming for the MIT ProgrammableBrick by beginning with manual controlof the elements of the brick and grad-ually progressing to writing programs.Users are presented with a simulated ver-sion of the Programmable Brick in whichthe parts can be manipulated; users canchange the speed of a motor connected tothe simulated brick by typing in a valueor using arrow buttons to increase or de-crease the value. Once users are comfort-able with manipulating the values of mo-tors and observing the values of sensorsin response to different types of actions,they can double click on the representa-tion of a motor or sensor and bring up arule editor for that object. The rule edi-tor provides buttons to add conditionalsor initial values to control the behavior of the brick. Conditionals are provided in atemplate form where users only have totype the names of objects they want to useand arithmetic operations. There are alsobuttons for increasing and decreasing thepriority of the current rule.

CURLYBOT : MIT MEDIA L AB, 2000 [Freiet al. 2000]. Curlybot is an educationaltoy for children aged four years and older.It consists of a two-wheeled vehicle withelectronics that allow it to record its mo-tions. The Curlybot has a single buttonand a single LED. The LED is used to in-dicate whether it is in record mode (red)or playback mode (green). When a childwants to record a motion, he or she pushesthe button, demonstrates the motion, andthen pushes the button again, which stopsrecording and starts replaying the mo-

tion. The motion is repeated until the but-ton is pushed again, turning Curlybot off.While Curlybot cannot provide the com-plexity of a full programming language, itdoes allow children to gain intuition aboutrepeated motions. The designers describehow sensors could be added to Curlybot toallow children access to if and while state-ments, but these additions have not beenimplemented.

(3) Provide Multiple Mechanisms forCreating Programs. Entering programsas text can be much harder than alterna-tives such as direct manipulation or form-lling but often gives the student morepower. In a system that provides multi-ple mechanisms for specifying programsand represents the resulting program inall program formats, students can use aneasier method of program specication tohelp in learning a more complex, morepowerful one. The system in this cate-gory provides multiple methods, includ-ing standard text, for specifying programsso that students can leverage the simplermethods to learn to program in a standard,textual format.

LEOGO : UNIVERSITY OF C ANTERBURY , 1997[Cockburn and Bryant 1997]. Leogo (seeFigure 12) is a system that producesdrawings similar to the Logo turtle (seeSection 4.1.2). However, rather thanconcentrating on one method for creating programs, it provides three: a typed syn-tax similar to Logo, a direct manipulationinterface in which the turtle is draggedaround and his actions are recorded, andan iconic language which contains tem-plates for dening structures and using commonturtle commands. Motions areex-pressed in all code styles simultaneously;when the turtle is dragged forward 15units, the text window shows forward 15,and the iconic window shows forward 15in icons so it is possible to learn someof the iconic and typed languages using direct manipulation.

3.1.2. Structuring Programs. These sys-tems concentrate on the structure of codeand how it is organized rather than onthe syntax of short segments of code. Thissection includes systems that have tried



17/55


Fig. 12 . The Leogo interface showing iconic, direct manipulation, and textual programming.

new paradigms for programming. Thereare two groups hereones that are chang-ing the paradigm, and ones that are try-ing to make changed paradigms moreunderstandable.

New Programming Models. These sys-tems explore new paradigms for organiz-ing code.

P ASCAL: INSTITUT FUR COMPUTERSYSTEME ,1970 [Wirth 1993]. The rst version of Pascal was created in 1970 for use inteaching programming, particularly sys-tems programming. At the time, theother available languages were Fortran,Cobol, and Algol, none of which supportedthe Structured Programming proposed byDijkstra [1969]. Pascal was introduced inbeginning programming classes in 1971to enable professors to teach StructuredProgramming to their students in theirrst course. Although Pascal wasdesignedwith teaching in mind, the improvements

in the language can be seen as general im-provements in programming languages. Algol, one of the primary inuences, hadambiguities in the ways nested ifscould beinterpreted; Pascal removed these. In ad-dition, Pascal added new basic types andthe ability to dene special purpose typesthrough record statements.

SMALLTALK : X EROX PARC, 1971 [Kay1993]. The rst version of Smalltalk wascreated in 1971 at Xerox PARC as thelanguage for the KiddyKomputer, AlanKays original name for a portable com-puter designed for use by a child. WhereBasic attempted to provide a simpler pro-gramming language by reducing the num-ber of commands and removing unneces-sary syntax, theLearning Research Group(LRG) at PARC concentrated on the modelof programming. The group wanted to cre-ate a programming language with a sim-ple model of execution and a method of



18/55


programming that could accommodatea wide variety of programming styles.Smalltalk was based around three ideas:(1) everything is an object, (2) objects havememory in the form of other objects, (3)and objects can communicate with eachother through messages.

PLAYGROUND : A PPLE COMPUTER , 1989[Fenton and Beck 1989]. Playground isan object-oriented programming envi-ronment designed to allow children tocreate their own graphical objects andgive them behavior. The programming model was based on a biological metaphorin which all objects are independentorganisms; the model was inuencedboth by Minskys Society of Mind [1986]and by classical ethology (the study anddescription of animal behavior). Eachobject has its own sensors, effectors, andprocessing elements so it can act inde-pendently. Programming in Playground isrule-based; rules describe both the actionand the circumstances under which itshould occur. Students specify rules foreach object using a natural-language-inuenced scripting language. One of thesuggested projects for the system is a virtual aquarium with different species of sh and plankton that feed on each other. A sh might have a rule that caused itto eat an algae cell if it saw one and washungry. A larger sh might eat a smallersh.

K ARA : ETH Z URICH , 2001 [Hartmannet al. 2001]. Kara is a graphical program-ming language based on Karel the Robotthat uses nite state machines to orga-nize procedures (see Figure 13). Kara canmove, turn, pick up and place clovers,and detect tree stumps and cloversthesecommands and questions are representedgraphically. In each state, the user can askquestions of Karas current position and,based on the answers to these questions,supply a sequential listof instructionsandthe name of the next state in the ma-chine. The nite-state machine diagramof the program is provided to show thestructure of the program and to allow theuser to select a preexisting state to edit.Theuseof thesimplenite-machine modelfor programming allows the Kara environ-

ment to be completely graphical; no typ-ing is necessary which is an advantage forbeginning programmers. In addition, toaid the transition from introductory pro-gramming in Kara to real programming,the authors have supplied JavaKara, anenvironment that provides a transitionto Java; MultiKara, an environment thatintroduces concurrent programming; andTuringKara, an environment that allowsstudents to experiment with Turing ma-chines in a two-dimensional plane.

Making New Models Accessible. Some pro-gramming styles, such as object-orientedprogramming, can be difcult for begin-ners to understand but can be helpful ei-ther in organizing larger programs or rep-resenting particular types of behaviors.Rather than requiring novice program-mers to learn multiple styles of program-ming, thesystems in this category attemptto make these more complex, but ulti-mately helpful, styles of programming ac-cessible to novice programmers.

LIVEWORLD : MIT MEDIA L AB, 1994[Travers 1994]. Liveworld is an object-oriented programming environmentbuilt to improve on Playground (seeSection 3.1.2). In Playground, creating and interacting with graphical elementsis very simple, but interacting with therules and attributes that govern thebehavior of the objects is much moredifcult. Liveworld attempts to createa graphical interface for the rules andattributes of objects so they are moreaccessible to novice programmers. Theinterface is similar to a hierarchicalbrowser (see Figure 14); parts of objectscan be opened, revealing the details of those objects. The user can dive downand change the Lisp code controlling the behavior of objects or simply use theobjects, depending upon how much detailthe user of the system wants to see. Thisallows novice programmers to use morecomplicated objects as black boxes whichwould have been difcult in Playground.

BLUE ENVIRONMENT AND BLUE J: U NI- VERSITY OF S YDNEY , 1996 [Kolling andRosenberg 1996b], [Kolling et al. 2003].



19/55


Fig. 13 . A screenshotof Kara showing a nite-state machine with threestates: enter, exit, and stop. Below the state machine are Karas instruc-tions based on whether there are tree stumps beside her. Each line con-tains instructions for a given scenario. For example, if there is a stumpon Karas right and not on her left, she should move forward and go tostate enter.

The Blue environment and BlueJ aredevelopment environments designed tosupport object-oriented programming inthe Blue language and Java, respec-tively. The authors of the Blue environ-ment and BlueJ believe that IntegratedDevelopment Environments (IDEs) forobject-oriented language should encour-age users to develop and test individualclasses rather than requiring users to al-ways create complete programs. Yet, mostcommon Integrated Development Envi-ronments (IDEs) for object-oriented lan-guages such as Java and C++ still re-quire students to build full programs that

have a single entry point. In contrast,the Blue environment and BlueJ provideusers with a class-testing bench whichthey can use to instantiate individualobjects, call their methods, and inspecttheir internal data. This allows users totest individual objects outside of the con-text of the running program, better sup-porting an object-based design. The Blueenvironment and BlueJ also supportobject-oriented programming by explicitlyrepresenting the relationship between theobjects in a graphical tree. Users can clickon a particular class to view the code forthat class. Compiling and debugging are



20/55


Fig. 14 . (a) A simple world in Liveworld containing two objects, an oval and a turtle. Theturtle is open so that the user can see its details. (b) An example of Lisp code used inLiveworld to turn a turtle.

also supported in the environment, simi-lar to other commercially available IDEs.

K AREL++: P ACE UNIVERSITY , 1997 [Berginet al. 2001]; K AREL J ROBOT: P ACE UNIVER -SITY , 2000 [Bergin et al. 1996]; J. K AREL :UNIVERSITY OF W ATERLOO , 2004 [Becker2004]. Karel J Robot, J. Karel, andKarel++ are versions of Karel the Robotthat concentrate on preparing studentsfor object-oriented programming ratherthan procedural programming. Karel JRobot and J Karel use Java-style syntax;Karel++ uses C++ style syntax. Ratherthan creating procedures to teach Karelto turn right, students subclass a ba-sic robot to create a right-turning robot.These systems all leverage off the successof the original Karel the Robot to attemptto introduce object-oriented programming early so that thinking and programming in an object-oriented manner will seemmore natural to students.

3.1.3. Understanding Program Execution. A syntactically correct program may notper-form the actions that the student au-thor intended. For beginning program-mers, understanding how programs areexecuted and how to nd mistakes in theirprograms can be difcult. The systems inthis category try to help students under-stand what happens during the executionof programs either by placing program-ming into a concrete setting or by providing a physically-based model of howprograms are executed in more general-purpose languages.

Tracking Program Execution . A TARI2600 BASIC: A TARI , 1979 [Robinett 1979].The Atari Basic Cartridge allowed chil-dren to write short programs in a vari-ant of the Basic language and watch themas they executed (see Figure 15). AtariBasic divided the screen into six regions:the Program region which displayed thechilds program; the Stack region whichdisplayed expressions as they were evalu-ated; the Variables region which displayedeach variable and its current value; theOutput region, which displayed all pro-gram output; the Graphics region, a 2D-graphical region with sprites; and theStatus region which displayed the currentexecution speed of the interpreter and theamount of remaining memory. Atari Ba-sic contained simple support for observing what was happening as the program ex-ecuted, similar to the supports found inmany debuggers. As a childs program ran,several parts of the display changed to re-ect the current state of the program: aprogram cursor showed the current line of code being executed; the stack updated asexpressions were added or evaluated; the values of variables changed as appropri-ate; sprites might move in the graphics re-gion; and the program might play a sound.

Make Programming Concrete: Actorsin Microworlds . Most introductory pro-grams in general-purpose languages arefairly abstract; the computer performsarithmetic operations on numbers andstores the results in invisible registers,



21/55


Fig. 15 . A simple program in Atari 2600 BASIC. The areas of the screenupdate to show the current position and state of the program.

making it difcult for students to under-stand and correct problems in their pro-grams. The microworld, inspired by theLogo turtle (see Section 4.1.2), attempts tomake programming more concrete by in-troducing students to programming con-structs through controlling the behaviorof an actor in a simple, physically-basedworld. The actors usually perform onlya few actions, resulting in small lan-guages that students can master morequickly than general-purpose languages.Microworld-based systems also typicallyinclude simulators that allow studentsto watch the progress of their programs.These simulators require the states of mi-croworlds to be graphically visible. Using microworlds, students can quickly gain fa-miliarity with many of the control struc-tures like if-statements and loops, allow-ing them to devote more time and energyto mastering the syntax and new com-mands when they move on to general-purpose languages.

K AREL : C ARNEGIE MELLON UNIVERSITY ,1981 [Pattis 1981]. Karel the Robotis one of the most widely-used mini-languages, originally designed for use atthe beginning of a programming coursebefore the introduction of a more general-purpose language. Karel is a robot that in-habits a simple grid world (see Figure 16)with streets running east-west and av-

enues running north-south. Karels worldcan also contain immovable walls andbeepers. Karel can move, turn, turn him-self off, and sense walls half a block fromhim and beepers on the same corner ashim. A Karel simulator allows studentsto watch the progress of their programs,step-by-step. Unlike many of the systemsdiscussed in this article, Karel is sup-ported by a short textbook, making it eas-ier for teachers to incorporate Karel intotheir classes.

Students can create procedures using Dene-New-Instruction (see Figure 16),but variables and data structures are notsupported in the language. The syntaxwas designed to be similar to Pascal (seeSection 3.1.2) to ease the transition fromKarel to Pascal after the rst few weeksof an introductory programming course.There are a number of other robot-basedmicro-worlds that are described in a sur- vey of mini-languages [Brusilovsky et al.1997].

J OSEF THE ROBOT: A CADIA UNIVERSITY ,1983 [Tomek 1983]. Like Karel, Josef isintended to introduce programming to be-ginners using a robot, Josef, in a simu-lated world. Josef lives in Wolfville whichis represented by an ASCII map; userscan replace the map of Wolfville with oneof their own choosing. He knows how toturn left and right, and move forward. The



22/55


Fig. 16 . Left, a simple Karel world with Karel in a room and a beeper outside the door. On the right,a program that will move Karel to the beepers location and have him pick up the beeper.

user can also set the speed at which Josef moves. However, unlike Karel, Josef cansay and listen for text strings, enabling input-output programs. Additionally, hecan drop text markers (e.g., the string cat)similar to Karels beepers anywhere in hisworld. Unlike Karel, Josef was intendedfor use in a full semester of programming for non-Computer Science majors. To sup-port a full semester of use, it includesmany more programming constructs thanKarel such as parameters, variables, andrecursion.

TURINGAL : UNIVERSITY OF PITTSBURGH ,1991 [Brusilovsky 1991]. Turingal is amicro-world-based language in which theactor is a Turing machine and the worldis the innite tape designed to give stu-dents exposure to the standard program-ming constructs as well as the classicTuring machine. The instructions in thelanguage allow the actor to move left andright along the innite tape as well asread and write symbols on the tape. LikeKarel, the basic instructions are easy to visualize. The Turingal language supportsconditional, loop and case statements and

procedures so that students can gainexperience with them in a visual set-ting. The language uses Pascal syntax(see Section 3.1.2) to ease the transitionfrom Turingal to Pascal. In support of acomputer literacy course for Russian highschool students, Brusilovsky also createdTortoise, a micro-world based on Turingalwhich uses a two-dimensional eld of sym-bols to make it more attractive to youngerstudents [Brusilovsky et al. 1997].

Models of Program Execution . Ratherthan creating a language that has asimple, physical interpretation, the sys-tems in this category provide physically-based metaphors for explaining actions ina more general-purpose language. Thesemetaphors can help students both toimagine the execution of their programsand perhaps more clearly understandwhy their programs do not perform asexpected.

TOONT ALK : A NIMATED PROGRAMS , 1996[Kahn 1996]. ToonTalk uses a physi-cal metaphor for program execution. InToonTalk, cities and the creatures and



23/55


Fig. 17 . A view of ToonTalk from inside a house. Marty the Martian provides information aboutobjects and what they can do.

objects within those cities represent pro-grams (see Figure 17). Most of the compu-tation takes place inside of houses wheretrainable robots live. Robots can commu-nicate with robots in other houses using birds that carry objects back to their nests.Using interaction techniques commonlyfound in videogames, users can navigatearound the cities, pick up tools, and usethose tools to affect objects. Users can con-struct programs by entering the thoughtbubbles of robots and showing them whatthey should do using standard ToonTalktools.

PROTOTYPE 2: V ICTORIA UNIVERSITY , 1998[Gilligan 1998]. Prototype 2 personiesthe ow of control in a computer, us-ing a clerk following instructions. Theclerk can interact with calculators, I/O devices, worksheet machines, and his clip-board in executing a program. Calculatorsrepresent the computers math proces-sor, I/O devices represent communicationwith the computer user, the clipboardrepresents the program stack, and the

worksheet machines produce stacks of worksheets that represent the instruc-tions in user-dened subroutines. Ratherthan imagining the internals of a com-puter, a novice programmer can imaginethe clerk walking around a room inter-acting with calculators, I/O devices, work-sheet machines, and his clipboard, and ex-ecuting the instructions specied on hisclipboard. This model was used in the cre-ation of a programming by demonstration-based system in which the user plays thepart of the clerk and demonstrates the ac-tions the clerk should take. The systemrecords these actions. While Prototype 2uses an anthropomorphic metaphor, thesystem does not include a graphical rep-resentation of the clerk and the objects inhis world; instead it is a standard graph-ical user interface with sections of the in-terface that represent each of the objectsin the clerks world (e.g., the calculator,I/O devices, etc.) that the novice program-mer can use to demonstrate how the clerkshould behave.



24/55


3.2. Learning Support

Systems in the previous category exam-

ined ways to make the process of learn-ing to program easier by simplifying themechanics necessary to write a program.The systems in this category try to easethe process of learning to program by providing basic educational supports such asprogressions of projects that gradually in-troduce new concepts or ways for stu-dents to connect with and learn from eachother.

3.2.1. Social Learning. Some of the mosteffective learning is done in a social con-text where more than one person is work-ing with a problem. Since programming isknown to be hard and children often learnmore effectively in groups, perhaps it mayhelp the learning process to provide a so-cial context in which learning can occur.The systems in this category investigatedifferent methods for allowing students towork together, colocated and over a net-work connection.

Side-By-Side . Most computer inter-faces are designed for single users. Con-sequently, when groups of children use astandard mouse, monitor, and keyboardsetup in learning, one child tends to dom-inate the process. The systems in thiscategory use tangible interfaces to allowmultiple students in informal groups towork together in solving programming problems. Because of the difculty of rep-resenting the wide variety of program-ming constructs in a tangible form, thesesystems concentrate on small subsets of programming.

A LGOBLOCK : NEC I NFORMATION TECHNOL -OGY RESEARCH L ABORATORIES , 1995 [Suzukiand Kato 1995]. The authors of AlgoBlockwanted to create an active learning com-munity among children learning to pro-gram in which children can share notesand techniques, and learn from each other.They created AlgoBlock, a set of blocks,each of which corresponds to a simple com-mand in Logo. The blocks can be connectedtogether to form programs that control themovements of a submarine in a maze. Theblocks are tangible and large enough that

they can be arranged on a desk that sev-eral students can work around. This al-lows students to work with the blocks ina social context, learn from each other,and communicate what they are learning.The tangible nature of the blocks makes iteasy for children to take turns manipulat-ing the blocks and communicating aboutwhich pieces should be placed where. The AlgoBlock project demonstrates that, in asuitable environment, children will worktogether in building programs. However,the blocks supported a limited set of pro-gramming constructs and there four thechildren were not able to explore con-cepts like procedures, parameters, or con-trol structures.

T ANGIBLE PROGRAMMING BRICKS : MITMEDIA L AB, 2000 [McNerney 2000].Tangible Programming Bricks are phys-ical Lego blocks that can be stackedtogether to form programs. The designersintent in creating these was to providea simple interface to appliances andtoys and to create a programming environment that would allow childrento collaboratively explore ideas. Whilethe work concentrated on the hardwareimplementation of the Lego blocks, thedesigner created three prototype environ-ments using Lego blocks that representcommands. To allow a greater varietyof commands, users could insert a smallcard (e.g., microchip) into a block. Eachblock could accept a single card, allowing users to communicate with other blocks via IR transmission, supply parametersto commands, sense the environment, ordisplay variables. The three prototypelanguages allowed children to teach toycars to dance, kitchen users to programmicrowaves, and toy trains to react tosignals along the side of the tracks inunique ways. By stacking blocks togetherwith accompanying cards, if necessary,users could construct simple programs.

Networked Interaction . Rather thantrying to move away from the commonsingle-user, single-computer paradigm,the systems in this category attempt toallow students using different machinesto work together over the network. While



25/55


Fig. 18 . A Moose Crossing script that allows Mooseusers to pet Rover. When a user pets Rover, they aretoldYou petRover.If they areone of Rovers friends,then Rover wags his tail.

thesystemsdesigned forstudents working side-by-side can assume all children cansee the state of the current program andwhat other children are doing, program-ming systems designed for network useneed to explicitly support the exchange of this kind of information.

MOOSE C ROSSING :MITM EDIA L AB, 1997[Bruckman 1997]. Moose Crossing isa networked programming environmentbuilt for children. It is an adapted text-based MUD(multi-user dungeon) in whichchildren can use an object-oriented script-ing language to create spaces and char-acters that inhabit a textual world (seeFigure 18). Children create spaces andcharacters similar to those found in textadventure games such as castles completewith secret passages that other childrencan explore. Once their projects are com-pleted, any child in the Moose Crossing environment can interact with them. Inaddition, the environment allows childrento view the scripts controlling any objector character in the environment and chatwith children who are currently loggedonto Moose Crossing. In general, childrenwork alone on projects but one child willoften use another childs project as an ex-ample. Children can ask another user forhelp or advice. The Moose Crossing com-munity provides a source of help, role mod-els, and positive feedback for users of thesystem as they create their own projects.

PET P ARK : MIT MEDIA L AB, 1998[DeBonte 1998]. Pet Park is an explo-ration of the ideas of Moose Crossing in a 2D-graphical domain rather than atextual one. Children can choose one of 5 dogs to be their pet. Each dog comeswith a few animations such as wagtail, jump, walk, laugh as well as basic oneslike wait, turnLeft, say, and so on. Users

can combine these simple commandsto create their own animations using atextual scripting environment or a set of graphical blocks representing each com-mand. As in Moose Crossing, Pet Park isa networked programming environmentin which children can talk, ask each otherfor help, and show off their creations.While in Moose Crossing children createspaces by describing them with text in PetPark, creating a space requires graphicalobjects. In response, the system providesa variety of furniture, objects, and rooms.Furniture and rooms can be programmedto react to simple events such as avatarscoming near them.

CLEOGO : UNIVERSITY OF C ANTERBURY , 1998[Cockburn and Bryant 1998]. Cleogo isa networked version of Leogo (describedearlier) that allows children to see andinteract with the same Leogo workspace.Rather than concentrating on building a community of programmers, Cleogocreates a shared environmentthe cur-rent program being editedand allowsmultiple children to see and manipulatethat environment. Cleogo does not at-tempt to provide children with a wayof communicating with each other abouttheir project. Instead, it assumes that theyare either in the same room or can talkto each other using the phone or someequivalent.

3.2.2. Providing a Motivating Context. Mo-tivation can be a key element in learning;if students want to accomplish a partic-ular goal, obstacles they encounter whilelearning to program will not deter themas much. The systems in this category at-tempt to provide beginning programmerswith goals to achieve through program-ming that thedesignersbelieve novicepro-grammers will nd motivating.

ROCKY S BOOTS /ROBOT ODYSSEY : THELEARNING COMPANY , 1982 [Robinett andGrimm 1982]. Rockys Boots was one of the rst educational software products forpersonal computers to successfully use aninteractive graphical simulation as alearning environment. The game allowschildren to connect logic gates (AND,OR, NOT and ip-op) together to create



26/55


Fig. 19 . A puzzle from Rockys Boots in which the player is asked to create a circuit that separatesblue crosses from the other shapes. When the circuit is switched on, shapes move up the right sideof the screen. When they enter the white rectangle, the shape sensors to the right of the rectanglecan detect them. The player is asked to attach a sequence of logic gates to the sensor that willactivate the boot (center) when a blue cross enters the box. The boot, when activated, will kick theshape out of the rectangle.

circuits using a joystick (see Figure 19).When the circuits are active, users canwatch the wires turn from white to orangeas the electricity passes through them.The game provides a series of puzzlesof increasing difculty in which theplayer is supposed to separate the shapesmatching a certain criteria from thosethat do not using logic gates, sensors thatcan detect certain kinds of shapes, anda boot that, when activated by a true value, kicks the current shape out of theline and off to one side. Robot Odysseyfollows the same basic pattern; the playerconnects gates together to solve problems.However, Robot Odyssey includes a largerselection of objects that perform animatedactions when they are activated (likethe shape-kicking boot), creating a widerset of possibilities for the behaviors of circuits.

A LGO A RENA : NEC I NFORMATION TECHNOL -OGY RESEARCH L ABORATORIES , 1995 [Kato

and Ide 1995]. In AlgoArena, playerswrite programs to control the behavior of sumo wrestlers ghting in tournaments.The programs are written in a languagebased on Logo. When a player has com-pleted a program, the player can log ontoa Web site and have his or her wrestlerght against another students wrestler.Over time, by analyzing thecircumstancesin which the players sumo wrestler losestournaments, the player is expected tolearn more complex ways to control thewrestler, perhaps querying the positionand posture of their opponent before de-ciding which moves to execute.

ROBOCODE : IBM A DVANCED TECHNOLOGY ,2001 [Nelson 2001]. Robocode is de-signed to help novices learn Java throughprogramming a robotic battletank for aght to the nish. The tutorial teachesnovices to subclass an existing battletankrobot and extend the robots capabilitiesusing standard Java and a set of classes



27/55


written for the Robocode environment.Upon completion of a robot, users can up-load their creation to a number of Websites or join a robotic battle league. Thedesigner of the system believes that theability to program robotic battles will provide enough motivation to get a novice pro-grammer over the hurdles of beginning toprogram.

4. EMPOWERING SYSTEMS

The systems in this category are builtwith the belief that the important aspectof programming is that it allows peopleto build things that are tailored to theirown needs. Consequently, the designers of these systems are not concerned with howwell users can translate knowledge fromthese systems to a standard programming language. Instead, they focus on trying tocreate languages andmethods of program-ming that allow people to build as much aspossible.

4.1. Mechanics of Programming

Systems that fail into this category aredesigned around the hypothesis that theprimary barrier for people attempting touse programming as a tool is the me-

chanical difculties of creating programs.These systems examine ways of improv-ing programming languages and alterna-tive ways for creating programs.

4.1.1. Code Is Too Difcult. Many re-searchers have examined the problem of making languages more understandableand usable for novices. While progresshas been made making programming languages more understandable, therestill are many barriers for novices try-ing to build their own programs. Thesesystems examine creating programs ei-ther through demonstrating correct be-havior or selecting actions through theinterface.

Demonstrate Actions in the Interface .The systems in this category examineways that users can program a system byshowing the system what to do through

manipulating the interface, without rely-ing on a programming language.

P YGMALION : STANFORD UNIVERSITY , 1975[Smith 1993]. Pygmalion was the rstprogramming-by-demonstration system.Unlike many of the systems that came af-ter it that concentrated on graphical objects, Pygmalion attempted to get peopleto write more abstract programs such asa program to compute the factorial of anumber. However, rather than building factorial by typing statements in a pro-gramming language, Pygmalion relied onediting an artifact. To create a factorialprogram, the user creates an icon withtwo subicons, one for the input and onefor the output, and draws a symbol to rep-resent factorial. The user can then enterremember mode, in which all of the ac-tions made by the user are rememberedby the system. Consequently, the user canprogram the computer by working out anexampleof how to compute factorial. How-ever, the user must anticipate the han-dling of the value one and test whether ornot the current value, say three, is equalto one, something that novices may notbe well prepared to do. If the user doesnot demonstrate his or her current ac-tions as the case for the current valuenot being equal to one, Pygmalion will notknow that one should be handled differ-ently and, consequently, will not promptthe user to demonstrate how one should behandled.

PROGRAMMING BY REHEARSAL : X EROX PARC, 1984 [Finzer and Gould 1984].Programming by Rehearsal was built tohelp nonprogrammers create educationalsoftware. It is designed around a theatermetaphor in which components of theinterface are performers who interactwith one another on a stage by sending and responding to cues. A user of thesystem would begin creating a piece of software by auditioning performers touse as building blocks, selecting theircues via a pop-up menu, and observing their responses to those cues. The userwould then copy the chosen performersonto the stage, placing and sizing themappropriately. The rehearsal portion of development consists of showing the



28/55


performers what actions they should takein response to user input or cues sent byother performers. Objects that accept userinput, such as buttons, have cue sheetsthat allow users to ll in their responsesto those user inputs. Users can press aclosed eye icon to tell the system to beginobserving their actions. Then, by selecting cues from the menus of other performers,they can show the system how to react tothose cues. By pressing the eye icon again,users indicate they have nished. Thesystem comes with 18 basic performersthat users can audition and use in theirown creations. Additionally, the systemallows users to create new performersby combining existing performers andteaching them new cues. While Pro-gramming by Rehearsal does allow usersto access the underlying programming languages (Smalltalk), the system wasdesigned to allow nonprogrammers tocreate educational software without re-quiring them to program at the Smalltalklevel.

MONDRIAN : MIT, 1992 [Liebermann1993]. Mondrian is a programming-by-demonstration system for drawing andgraphical editing in which commands areshown with domino icons that depict thebefore and after states for that command.To execute a command, users select thecommand icon and then select the objector area to which the command shouldbe applied. The user can create newcommands in a storyboarding style byshowing how to do each step in the newcommand. These steps are displayed atthe bottom of the screen in comic bookformat with a short caption describing each step. Drawing a rectangle on thescreen would show a box with the newscreen state captioned by rectangle.If the user then moves the rectangle,a move domino would appear besidethe rectangle domino in the denitionof the new command. New commandscreated by the user are displayed in thesame domino style as the commands builtinto the system. In addition, the systemprovides speech synthesis capabilitiesto give an English description of what acommand does.

Demonstrate Conditions and Actions .Like the previous category, the systems inthis category try to avoid forcing users toexpress their intentions in code. However,instead of demonstrating programs by per-forming actions in theuser interfaceas thesystems in the previous category did, thesystems in this category allow users to de-pict the conditions in which they want theprogram to perform an action and the re-sults of that action.

A GENT SHEETS : UNIVERSITY OF COLORADO ,1991 [Repenning 1993; Repenning and Ambach 1996]. In AgentSheets (seeFigure 20), users can create simulationsby specifying the behavior of sprites ina 2-dimensional grid-based world. Spritescan move to new grid positions, makesounds, andchangeappearance. Users cancreate programs using graphical rewriterules; users select conditions (congura-tions of icons in the world or relative toeach other) and show the system whatshould happen under these conditions bymoving the agents to their new positions.In addition, Agentsheets provides tools forcreating analogies between agents. For ex-ample, if a user wants a train to follow aset of train tracks in exactly the same waythat a car follows roads, he or she can usean analogy tool to easily specify this. Useof analogies provides an easy way to reusecode.

CHEM TRAINS : US WEST A DVANCED TECH -NOLOGIES , UNIVERSITY OF COLORADO , 1993[Bell and Lewis 1993]. ChemTrains isa pictorial rule-based language that at-tempts to make it easy for people tocreate a wide variety of behaving pic-tures. ChemTrains is similar to Stage-cast (see the following) in that usersshow both the conditions and results of a rule through pictures. In ChemTrains,the pictures used to specify conditions andresults are interpreted as patterns of con-nections rather than collections of pix-els. For example, in simulating an ANDgate, if there is any box with a zero con-nected to the AND gate (from any direc-tion and any distance away), the outputof that gate should become zero. A similarstatement in Stagecast would only work if the zero connected to the AND gate was



29/55


30/55


Fig. 21 . This drawing shows an example of howusers create rules in Stagecast. On the left side arethe conditions in which each rule should be applied.On the right, the results of each rule are shown. Inthis drawing, if there is a raindrop with an emptyspace below it, the raindrop should move down. Oth-erwise, if there is a raindrop with an empty space onits right, it should move right.

inuenced by forces. Users can pick upobjects, move them, drop them, or throwthem using mouse gestures. Users canquery or change the state of objects bysending messages (represented by but-tons) to those objects. To connect a buttonto a particular object, the user drops thebuttononto that object. If theobjectunder-stands the message the button represents,the button sticks to the object, otherwiseit falls through. Buttons that require a pa-rameter have a little plug where userscan hook up a value for the parameter.

K LIK N PLAY : EUROPRESS , 1994 [Lionetand Lamoureux 1994]. Klik N Play is de-signed to allow the user to create sim-ple level-based games. Theapplication hasthree modes: a storyboard editor which al-lows the user to see all levels as thumb-nails, a level editor, and an event editor.The level editor allows the user to se-lect the background, add predened objects to the level, and provides users withthe ability to create their own objects andanimations for those objects. Users createanimations frame-by-frame with a bitmapeditor and use controls to set the speedand motion of objects. The event editoruses a table format and allows the userto specify actions for a variety of prede-

ned events (see Figure 22). Klik N Playsevents are based on collisions between objects, mouse and keyboard input, time, thestate of players, and the states of vari-ables and objects in the level. Corel dis-tributed an updated version of Klik N Playthat granted users the rights to sell theirgames under the name Click and Create.

EMILE : UNIVERSITY OF MICHIGAN , 1995[Guzdial 1995]. Emile is a program-ming environment written in Hypercard[Goodman 1987] that allows high schoolstudents to create physics simulations(see Figure 23). The environment provides support or scaffolding [Merrill andReiser 1993] that makes the process of programming (everything from dening the problem and breaking it into goalsto dening the behavior of a buttonwithin the interface) easier for beginning students. As the students become morecomfortable with the environment, theycan choose to use less support. InEmile, beginning programmerscreate pro-grams by assembling components: but-tons, textelds, and predened actions.Using menus and dialog boxes, stu-dents can select one or more actionsthat should happen when a given but-ton is pressed and ll in any neces-sary parameters for those actions. Asthey become more advanced, studentscan begin to use mathematical expres-sions, create their own actions by com-bining other actions, and eventually editHyperTalk (Hypercards scripting lan-guage) code themselves.

4.1.2. Improve Programming Languages.The designers of many of the teaching languages are concerned with how wellstudents can transfer the knowledgethey gain in the teaching language tomore general-purpose languages. Con-sequently, the designers of teaching languages have been hesitant to deviate very far from these general-purposelanguages. However, the systems in thiscategory endeavor to empower their usersto create interesting programs; whetherthe users of these systems can transfertheir programming knowledge to more



31/55


Fig. 22 . A view

lowering the barries to programming_a taxonomy of programming environments and languages for novice...

Documents