DL_one-third_page_4C:Layout 1  6/26/08  4:05 PM  Page 1

ACM Digital Library

www.acm.org/dl

The Ultimate Online
INFORMATION TECHNOLOGY
Resource!

• NEW! Author Profile Pages
• Improved Search Capabilities
• Over 40 ACM publications, plus
conference proceedings
• 50+ years of archives
• Advanced searching capabilities
• Over 2 million pages of
downloadable text

Plus over one million
bibliographic citations are
available in the ACM Guide
to Computing Literature

To join ACM and/or subscribe to the Digital Library, contact ACM:

Phone: [phone] (U.S. & Canada)
+ 1.212.626.0500 (Global)
Fax: + 1.212.944.1318
Hours: 8: 30 a.m.-4: 30 p.m., EST
Email: [e-mail]
Join URL: www.acm.org/joinacm
Mail: ACM Member Services
General Post Office
PO Box 30777

New York, NY 10087-0777 USA

questions are being addressed by researchers in the field of computing education research. Researchers in computing education draw on both computer science and education— neither field alone is sufficient. While we computer scientists understand computing from a practical, rational, and theoretical perspective, questions about education are inherently human questions. Humans are often impractical, irrational, and difficult to make predictions or proofs about. Computing education researchers are using experimentation and design to demonstrate we can address important questions about how humans come to understand computing, and how we can make it better. Research in computing education will pave the way to make “computational thinking” a 21st century literacy that we can share across the campus.

understanding computing
Before Programming

A research theme in the early 1980s was how to design programming languages so they would be more like natural languages. An obvious question, then, is how people specify processes in natural language. Lance A. Miller asked his study participants to specify file manipulation tasks for another person. A task might be “Make a list of employees who have a job title of photographer and who are rated superior, given these paper files.” Miller studied the language used in his participants’ descriptions. ²

One of Miller’s surprises was how rarely his participants explicitly specified any kind of control flow. There was almost no explicit looping in any of their task descriptions. While some tested conditions (“IF”), none ever specified an “ELSE.” He found this so

 

figure 1: traditional conditional structure.

if (value < 10) then value = value + 10; else sum = sum + value; end if

figure 2: new conditional structure.

if (value < 10): value = value + 10; not (value < 10): sum = sum + value; end (value < 10)

surprising that he gave a second set of participants an example task description, without looping and no ELSE specification. The second set of participants easily executed the task description. When asked what they were doing if the condition was not met, or if data was exhausted, they replied ( almost unanimously, Miller reports), “Of course, you just check the next person, or if there are no more, you just go on.”

Miller’s results predict some of the challenges in learning to program— challenges that are well-known to teachers of introductory classes today. While process descriptions by novices tend not to specify what to do under every condition, computers require that specificity. Miller’s results suggest what kinds of programming languages might be easier for novices. Programming languages like APL and MATLAB, and programming tools for children like Squeak’s eToys use implicit looping, as did the participants in Miller’s studies.

Twenty years later, John Pane and his colleagues at Carnegie Mellon University revisited Miller’s questions, in new contexts. ³ In one experiment, Pane showed his subjects situations and processes that occur in a Pacman game, then asked how they would specify them. The subjects responded with explanations like, “When Pacman gets all the dots, he goes to the next level.” Like Miller, Pane found that participants rarely used explicit looping and always used one-sided conditionals. Pane went further, to characterize the style of programming that the participants used. He found that over half of the participants’ task statements were in the form of production rules, as in the example. He also saw the use of constraints and imperative statements, but little evidence of object-oriented thinking. Participants did talk about accessing behaviors built into an entity, but rarely from the perspective of that entity; instead, it was from the perspective of the player or the programmer. He found no evidence of participants describing categories of entities (defining classes), inheritance, or polymorphism.

Pane’s results suggest that object-oriented thinking is not “natural,” in the sense of being characteristic of novices’ task descriptions. Since ob-