One of the postdocs in my office suite has this comic from the series PhD (Piled Higher and Deeper) on his door. While Greenfoot isn’t a scholarly publication, I assume I get +10 points for starting the post title with the word “On…”. But I digress.

In my last post, I discovered that it is incredibly easy to bring Greenfoot worlds to a screaming halt. Mind you, Greenfoot doesn’t crash, or anything silly like that. However, I did find it distressing that my program stopped running all of a sudden, and a huge swathe of angry, red text was thrown at me. It was so disturbing, even, that I took a screenshot of the text:

Angry red text.

Now, I know what this angry red text means; this is due, in part, to the fact that I’m a computer sciency type of person who knows a fair bit about a number of different programming languages. However, I’m confident a high school student just starting out with Java and Greenfoot will respond slightly differently. To understand just how differently they might respond, I would love to have the resources to carry out live-fire usability studies of Greenfoot in secondary and tertiary classrooms while Greenfoot is being developed, I’ll settle (for the moment) for a game of “what if.”

From the student’s perspective

I’ve spent a fair amount of time reading programs written by students dealing with syntax errors (PDF). How students respond to exceptional run-time behaviors is not something I’ve studied in-depth, but I feel comfortable doing a little bit of extrapolation from the data I have and know intimately.

Confident students

Some rare students read error messages to understand them. They look at the error, their program, the conditions under which the error occurred, and take that knowledge to heart. When they encounter other errors or exceptional behavior in the future, they are able to abstract from what they learned in their previous encounter, and deal with it confidently. The angry red text above becomes something they can recognize at a glance. I imagine that, over time, exceptions go from a pile of meaningless text (left) to something that the confident student quickly summarizes in a meaningful way (right):

Not-so-confident students

At the other end of the spectrum are students who struggle with the syntax of the language, not really understanding why a program works when a bracket is there instead of over there, nor do they understand how their friend was able to lean over and fix whatever was breaking their program so quickly! Coming to grips with the rules of the language (the syntax) and how their programs are actually executed (the semantics) are a deadly one-two combination that can leave them feeling helpless at the end of the day. “I’m just stupid”, or “I’ll never get this” are the battle-cries of the desperate and disenfranchised in the novice programming world.

When they get started, the angry red text is just that: an angry pile of red text (left). By the time they’ve seen the error the 10th, 20th, or 30th time in an hour, the student isn’t just confused: they’re disheartened at best, and ready to quit at worst (right).

Students in-between

I suspect that for the vast majority of the students, they muddle through. They learn to recognize some exceptions, wonder where others come from, and at the end of the day are glad they didn’t fail/passed/did OK/were amazed they almost got top marks, and so on. If this kind of exception is common in Greenfoot, though, they’ll walk away remembering it. “Oh, you’re using Greenfoot? Yeah, we used that in our first year; all kinds of errors you had to deal with, right?”

From the instructor’s perspective

Students really do say stuff like that to each-other. It’s kinda upsetting from the instructor’s perspective, because that’s all they remember from a long year of lecture preparation and marking. Why, we sometimes wonder, do we bother?

From the instructor’s perspective, I like to think that Greenfoot will help let us tackle some of these kinds of student perceptions. It is an interesting environment in which we can explore all manner of engaging simulations while exploring the Java programming language. But to tackle negative impressions of their first programming environment, I’m going to need some power, as an instructor, to limit the damage that students can do initially, and slowly give them more and more ways to hang themselves. Given my initial experiences with Greenfoot (limited though they are), I’d say that I initially want to minimize my students’ exposure to exceptions.

Exceptions are, in some ways, a leaky abstraction. In fact, I’ve explored this idea before while musing about first language choice for novice programmers. However, you cannot consider a language independent of its environment; there are many dimensions to programming languages, and the context in which they are used matters. In short, exceptions are a huge, gaping hole in Greenfoot’s World/Actor abstraction; from an instructor’s point of view, I’d like to have a way to manage those exceptions, limiting (or preventing) student exposure to them until I feel they’re ready.

Exposing students to Greenfoot, one exception at a time

While I like the notion of test-first programming, I have a hard time believing in trying to teach it from day one. Learning to write programs that just work is hard enough; then figuring out how to handle all the ways they might fail, and testing for that, is bonkers. It’s a way to create confused students. Likewise, in Greenfoot, I’d love it if it was impossible for my students to see an exception on day one. Or day two. In fact, for the first four weeks, I’d like it if it was damn near impossible for student programs to throw exceptions.

And then, in week four, I’d like to tell my students to switch Worlds, and start introducing them to World boundaries. We might start by programming defensively (using tests to demonstrate that our code never achieves these exceptional conditions), and slowly start handling the exception directly. Once they get the hang of basic exception handling from clearly observable conditions (running off the edge of the world, etc), we might start using exceptions in our own code—in the Actors—to report exceptional conditions of our own design.

And after all of this, we can move on to the really cool stuff—Actors that communicate with Actors running in other instances of Greenfoot (using XML-RPC, JavaRMI, or similar), or Actors whose behavior based on the results of calling a CGI on the WWW, or reading an RSS feed, or … who knows what! But all of these things require my students to be able to write code that handles exceptions, and understand what it means to program in the face of the unknown.

In conclusion

I suspect Greenfoot is powerful enough for me to make my dream a reality. I can, as an instructor, provide Scenarios that override the default World and Actor classes, and handle these exceptions in all manner of ways, all of which are of my own design.

Normally, I’d think about writing this post at the end of the week, but I have a dissertation to defend on Friday. That, to me, seems like an extended exercise in “exceptional behavior”… we’ll see how it goes…