I’ve been traveling quite a bit lately, and haven’t been able to get things up on the ‘net very easily. However, I thought it was important to drop a pointer to Michael’s blog post about a patent Microsoft has recently applied for. If you missed the Slashdot post pointing to it, you can catch it here.
Mercy.
I’ll categorize this under “exceptions” and “mistakes.”
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:
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.”
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.
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):
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).
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?”
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.
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.
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… 
|
All the world’s a stage, and this quote, often abused.
M. Jadud |
What can an Actor do? Not as pressing a question as What Would an Actor Do? (WWAD?), but certainly an important question never-the-less. I want to remind the gentle reader that I have many grand schemes about great, sweeping themes and stories about agent-based programming in Java using Greenfoot… but at the moment, I’m just wandering around. And in my wanderings, I’d like to make the mushrooms in my LumpWorld wander around, too.
Of course, I don’t know how to do that. I could try and use Google to find out how, or I could go back and read the tutorial. However, I want to try something a little different. I’ll read some documentation.
Now, I know some of you are saying “Matt! Reading documentation! That’s awfully extreme, isn’t it?” Well, my friends, it is. Very extreme. And, for the record, it is very, very exciting. And Greenfoot has plenty of documentation hidden inside it, if you know where to look.
Lets start with the Actor class. If I double-click on the Actor class, I get a whole mess of Java.
This mess-o-Java is not for the faint-of-heart. If you look at the top of the file, you’ll see that it is written by @author Poul Henriksen, which means that a crazy person wrote that code. And we all know what happens when crazy people write software. So be careful if you spend any serious time looking at this code. What is more interesting is in the upper-right-hand corner of this window: a little drop-down menu. It has two options: Implementation and Interface Go ahead and select Interface.
This is more like it! The interface documentation tells us about all the things we can do with an Actor object. For example, in my last example, I used the setRotation method; we can see that it is documented here, and not just in the Wombats tutorial. Along with it is a method called setLocation. The method summary is really quite straight-forward:
void setLocation(int x, int y)           Assign a new location for this object.
This method consumes two integers, and returns nothing. I’m guessing it is a magic teleport method, and probably should have been called magicTeleporter(int x, int y), because it will magically make your Actor jump to anyplace in the Greenfoot World. I’m going to take my existing act() method:
public void act() { lump_rotation = lump_rotation + 1; setRotation(lump_rotation); }
and I’m going to modify it just a bit. I’m going to make my mushrooms wander around while they’re rotating.
The neat thing about sitting down to a piece of software as rich as Greenfoot is that you can find things you don’t expect. Put another way, I can come to the table with all kinds of assumptions, pre-conceived notions, and expectations about how Greenfoot should or will work, and then be surprised when it doesn’t work that way. Since the point of this blog is to wander around Greenfoot “kicking the tires” (so to speak), I might as well talk about some of my failures along side some of my successes, no?
Here was my first attempt at making a Lump that would march across the screen:
public class Lump extends Actor { private int lump_rotation; private int lump_X; public Lump() { lump_X = getX(); } public void act() { lump_rotation = lump_rotation + 1; setRotation(lump_rotation); // Move the Lump around! lump_X = lump_X + 1; setLocation(lump_X, getY()); } }
My previous post explored making my Lumps rotate around their axes; this would have them spinning and marching around. However, this code has a significant problem that didn’t really make sense to me at first:
java.lang.IllegalStateException: The actor has not been inserted into a world
so it has no location yet. You might want to look at the
method addedToWorld on the Actor class.
at greenfoot.Actor.failIfNotInWorld(Actor.java:537)
at greenfoot.Actor.getX(Actor.java:103)
at Lump.<init>(Lump.java:23)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at greenfoot.core.WorldInvokeListener$2.run(WorldInvokeListener.java:150)You see, I put the call getX() in the constructor for my Actor. (The constructor is a special Java class method that is called when a new object is created. It always has the same name as the class—in this case, it is called Lump().) When I right-click to create a new Lump() object, everything is fine… until I try and put it in the world. At this point, the object is created, but it doesn’t yet exist in the world. So, everything goes badly for my Lump, and this exception is thrown.
That’s cool. Since this post is about reading documentation, I then went back to the documentation I mentioned earlier and started reading. Sure enough, the docs tell me that I can’t do what I tried to do. Because I’m a slow monkey, it looks like the documentation might become even more explicit about this point—that would be cool. While reading more carefully, I discovered the addedToWorld() method. This fits in thusly:
addedToWorld() is calledNow, I’m sure other nifty things happen in there, but this is enough for us to be getting on with.
Now that I’ve learned to stop fearing Greenfoot, and learned to love the documentation, my life has been much, much better. My next attempt at making my Actor wander around was much better.
public class Lump extends Actor { private int lump_rotation; private int lump_X; public Lump() { } public void addedToWorld(greenfoot.World world) { lump_X = getX(); } public void act() { lump_rotation = lump_rotation + 1; setRotation(lump_rotation); // Move the Lump around! lump_X = lump_X + 1; setLocation(lump_X, getY()); } }
Now, my Lump correctly drops into the World! Woot! What happened next, however, was not expected; I’ve created a video to demonstrate what I encountered next.
An exception! In particular, this text popped up on my screen: