My name is Des Traynor, I began a PhD (cryptically) entitled The Analysis and Synthesis of Student Profiling in Adaptive Learning Environments. My work primarily involves using solid software engineering techniques to incrementally build a cognitive model of learning to program.
The system will be created using empirical evidence gathered from first year programmers, and their mistakes. A detailed overview of how this will be attempted will be present (hopefully) at PPIG 04 in Carlow.
More information of my work is available at my website below.
I'm a Ph. D. student under Brad Myers, at the Human-Computer Interaction Institute at Carnegie Mellon. I've been following up on John Pane's work in the Natural Programming project, focusing more on how programming environments can be more helpful My project is called project Marmalade (Yes, its an acronym).
Much of my work has been driven by human factors research on the cognitive mechanisms of human error. I've done quite a few studies of the Alice programming system being developed here at CMU, in order to get a sense for the causes of software errors in the environment. I also recently submitted a journal paper on a framework and methodology for studying the causes of software errors in programming systems. The framework entails describing the causes of software errors in terms of chains of cognitive breakdowns, which consist of the type of cognitive failure, an action, the interface, and the programming information that was acted upon.
Using the framework, I've done a thorough analysis of the causes of software errors in Alice. Because Alice has a structured editing interface (though quite different from the structure editors of the past), syntax errors and type errors are entirely prevented. What is left is a cycle of debugging breakdowns, which lead to software errors, which lead to further debugging breakdowns.
My first attempt at preventing some of these errors was to design a debugging tool. The root cause of the debugging breakdowns was biased reviewing: when their program failed, programmers had a large space of hypotheses to consider about the cause of their program's failure, but they only considered a few and tested them insufficiently. To prevent these false hypotheses, I designed a debugging tool called the Whyline.
The Whyline allows programmers to ask questions about their programs' failure in terms "why did" and "why didn't" questions, using a simple hierarchical menu. The menu contains the objects that have been changed or that have performed actions, as well as the objects that could have changed or performed actions in the code. The answers are given in terms of a precise dynamic slice on the runtime history, giving programmers only the runtime actions directly related to the program output (or lack thereof) in question.
I hypothesized that by allowing programmers to ask questions directly about a failure, they would only form hypotheses about the cause of failure at a surface level, and be less likely to go down unproductive debugging paths. In comparing programmers' performance in a study with and without the Whyline, this hypothesis was largely confirmed. Programmers without the Whyline were forced to form hypotheses about runtime behavior at the granularity of their code, requiring them to make faulty assumptions about their program's runtime behavior.
With the Whyline, their assumptions were either immediately addressed in the answer, or available in the answer after brief inspection. Overall, programmers spent an eighth of the time debugging and progressed 40% further through their task. For more details about the Whyline's functionality and the rationale behind its design, consult our CHI 2004 paper on the Whyline.
We think the Whyline is a good example of how a principled analysis of the causes of software errors can lead to a more helpful programming environment. In addition to refining the Whyline, we're also looking at issues of creating, modifying, and testing Boolean expressions, example code repositories and mechanisms for reuse, as well as novel ways of constructing code that are less structured than Alice but more than your typical text editor.
If you have any questions about our work, you can reach me at ajko(at)cmu.edu and Brad at firstname.lastname@example.org.