Ray Lischner
Oregon State University
Many students find it difficult to learn computer programming and computer science. Numerous studies have identified specific hurdles that students face; fewer studies have recommended remedies. A constructivist view suggests that students need help with their mental models: tackling the deficiencies of their preconceived models of computer programming, and constructing new, more effective models. A key difficulty that first-time students face is that the computer's inner workings are intangible. As concrete thinkers, these students would learn faster and better if they could manipulate a program directly, instead of treating a computer as a black box.
Some research has examined the kinds of errors that novice programmers frequently commit [2, 3, 4, 6, 7, 8]. A number of common patterns emerge, but the root cause seems to be that students ascribe human-like intelligence to the computer. They expect the computer to understand their intentions, regardless of how they write their source code.
Applying constructivism shows us what is happening: students enter the first programming course with a preconceived model of how a computer works [1, 5]. Usually, computers are seen as possessing intelligence, perhaps more intelligence than people. First progamming courses that do not directly address this existing model will inevitably be less effective that courses that do address the students' mental models.
Perhaps the biggest obstacle that students face in trying to overcome their basic mental model is that they the computer's inner working are intangible. They cannot see in any tangible form how dumb the computer actually is. Animating an algorithm shows an external view of how the algorithm works, but probably does not help break down the preconceived notions of a computer's intelligence.
I believe that students will learn more effectively if they are able to manipulate the computer's inner workings in a tangible form, and at the same semantic level as the programming language.
Some introductory courses teach students how to use a debugger. The problem with debuggers is that they are usually designed as professional tools, that is, the creators of the debugger assume the user already has a firm understanding of how a computer works: the user already knows the difference between local and global variables, understands the nature of a call stack, and so on. Thus, the debugger is not designed to teach the user about these constructs.
Also, most debuggers cannot reverse time and undo assignment statements and function calls--both abilities that I think are important to help students understand how programs work.
My goal is create a tool that lets students peer inside the computer, watch how a program runs, and manipulate the program while it runs. The student can run the program forward or backward, one step at a time, or continuously. When running continuously, the program can run at full speed or at a reduced speed--to help the student see what happens.
The student can examine the call stack, local variables, and global variables. Variables can be changed, and the history of each variable can be viewed. The program can be rolled back to where a varaible's value changed most recently.
A variable whose value contains references to other values can be shown pictorially, so students can see the structure of simple lists, trees, and graphs.
The student can explore "what-if" scenarios: starting at a specific point, the student can try different values or function calls and see what happens. The tool remembers all scenarios and can present the results so the student can compare.
The tool can keep track of multiple revisions of a function or class. The student can try different versions of the same code in the same session and compare results. The tool blurs the line between editing and running.
The tool is aimed at first-time programmers. It lacks advanced features, even features suitable for a CS2 course. To help students make the transition to the more advanced courses, the language it uses should be a proper subset of a popular teaching language. (Can you say, "Java"? Sure you can.)
I believe students who use the teaching tool will learn faster and better than students who use traditional tools. A straightforward experiment can measure the difference: randomly divide students into two sections; teach both sections the same, but one section uses the new tool for labs and the other section uses traditional tools. Ideally, students would be followed in subsequent classes to see if any differences persist.
Other visualization and teaching tools have addressed parts of what I describe above. I have not yet performed a complete literature search, but I am aware of the following:
BlueJ - a Java environment that hides some of the syntax details and lets students focus more on conceptual and design issues.
DrScheme - a Scheme environment that promotes teaching.
LearningWorks - a Smalltalk environment for teaching.
I am currently working on an M.S. degree, to be completed in June 2001. I have not started any work on my Ph.D. research ideas. After I complete my M.S., I will probably return to being an instructor at Oregon State and defer work on a Ph.D. until after my wife finishes her Ph.D. (She's "almost" done.) My Master's research is entirely unrelated to the issues presented here.
At the Doctoral Consortium, I hope to refine my research ideas, to better prepare me for the time when I eventually return to my Ph.D. studies. The DC would be a good time, for example, to learn that I am heading in a totally hopeless direction and should choose something more practical.
[1] Ben-Ari, M. Constructivism in computer science education, in SIGCSE Bulletin, 30(1), March 1998, pp. 257-61.
[2] Du Boulay, B. Some difficulties of learning to program, in Journal of Educational Computing Research, 2(1), 1986, pp. 57-73.
[3] Ebrahimi, A. Novice programmer errors: language constructs and plan composition, in International Journal of Human-Computer Studies, 41(4), 1994, pp. 457-80.
[4] Fleury, A. E. Programming in Java: student-constructed rules, in SIGCSE Bulletin, 32(1), March 2000, pp. 197-201.
[5] Norman, D. A. Some observations on mental models, in Mental Models. Lawrence Erlbaum Associates,1983. pp. 7-14.
[6] Sleeman, D., et al. Pascal and high school students: a study of errors, in Journal of Educational Computing Research, 2(1), 1986, pp. 57-73.
[7] Spohrer, J. C. and Soloway E. Analyzing the high frequency bugs in novice programs, in Empirical Studies of Programmers, 1986, pp. 230-51.
[8] Spohrer, J. C. and Soloway, E. Novice mistakes: are the folk wisdoms correct? in Communications of the ACM, 29(7), July 1986, pp. 624-32.