Greenfoot lets students jump right in and start playing with objects and classes. The concepts of object and class are very hard to teach. They're my biggest hurdle in teaching programming. Greenfoot looks like it may be the perfect tool for clearing that hurdle.
It simplifies the relationships between classes, objects, and methods without concealing the useful information. It ties actions like instantiation and method calls to visible manual activities with visual results. You can say, "I'm going to instantiate a wombat," then do it. The Wombat class has a menu item creates a new wombat object. Similarly, subclassing and inheritance can be demonstrated from simple menu actions.
Greenfoot isn't just for the teacher's projector. On the student's computer it runs framework programs called scenarios that are basically tile and sprite programs. They are fun and easy to tweak and run. The system invites exploration.
The underlying code is real Java, not a canned version of an OO language. Theoretically this means the programs produced with Greenfoot can be as extensive as Java itself. It generates stand-alone applications and applets. The question is whether students will willingly grow out of using Greenfoot as a simple sprite game generator to develop ideas that Greenfoot doesn't implement as easily.
I'm trying out Greenfoot with a couple of live students now, aged 13 and 16. Both have been exposed to Java, neither really got classes or objects. We spent about 40 minutes watching a demo of Greenfoot by Michael Kölling. The demo wasn't targeted to students, but by the time we reached the Q&A session they were both aching to get their hands on Greenfoot. I set them loose, with no further instruction, just making myself available for questions (while I played with it myself.)
Both definitely had fun. Neither wanted to quit when time was up. There wasn't any time for a debrief to see what was learned aside from the fact that Greenfoot can do a pleasant job of filling an afternoon. That by itself has value if it shows you can control a machine without being an otaku egghead.
For myself, I found it to have some rough edges that would make it tough for non-programmer teachers to use in class. This isn't a problem for me, but I had hoped this might be something I could present to others whose skills largely restrict their classes to typing, MS Office, simple painting apps, and the occasional session of Minefield or Solitaire. I don't think it's ready for them to use on their own. But I'll see about sitting a non-programming instructor down with it and see what they make of it.
It might work for an instructor with the right mindset:
- don't sweat what you don't get,
- if something doesn't work then don't do that--do something else,
- let the students research their own solutions online,
- and share among themselves,
- then grade results and progress, not code.
There are questions I have about Greenfoot that I'll be looking for answers to before I recommend it. Does its use really translate into programming? Or will students resist going beyond menu-driven image replacements and simple changes of constants? Will they go into shock at the sight of code in the editor window? How much of my time will it take to set up scenarios to introduce and illustrate new concepts and constructs? Will attempts to shift gears from unstructured play to directed learning cause a revolt?
Where does it fit with other instruction? After a few command line exercises or as a light intro? Is there a point when a more conventional IDE should replace it? Will it be necessary to repeat concepts both in and out of Greenfoot so that they still make sense without Greenfoot's presentation?
More on my Greenfoot experiment soon. At this point, I'd say a teacher with programming skills could make excellent use of it to illustrate many basic OO concepts that are serious problems to non-programmer students.
And it's a heck of a lot of fun.
Posts
Webomator.com: Backward into the