A change of strategy

We’ve been plodding along for a few weeks now with Python, and a few boys in particular have amused me with the way they’ve played with the code we’ve used, particularly input and loops:

Enter password:

Wrong password, this computer will self destruct in 10..9..8..

Downloading virus…

downloading virus…

downloading virus…

We also had some fun with making the computers beep (thanks codeboom!).

But overall it felt slow, and some of the lower ability kids were finding it hard going.  Bear in mind that this cohort has done very little coding previously, if any at all, and they’ve been finding it very difficult to think in the logical way needed to build up algorithms.

So this afternoon we tried out Greenfoot.  I had originally considered it as a learning tool, but rejected it because coursework for GCSE seems console-biased, and it seemed any editor that would edit Java to run in the console seemed unnecessarily complex for our use.  However, I became interested to see what the kids would make of it.

We started with Mik’s videos, and soon we had turtles crawling and spinning merrily on screen.  The students who had previously seemed to lack motivation started experimenting and playing, and by the end of the lesson, curses over brackets and semi-colons aside, all agreed that they would like to see more Greenfoot.  Most importantly, they had experienced the wow factor that I had felt was lacking previously.

Scratch is misleading, in my opinion: it looks as though it’s designed for younger kids, and it’s very easy to click blocks together and do something, but in fact it can get very complex very quickly when they want to do something specific, and it can be frustrating when they see all the blocks there but don’t understand how to use them, especially when their perception is that it should be easy because of the child-like design.

Greenfoot can be just as complex, but it’s revealed part by part as they learn, rather than thrown at them all at once.  It feels grown-up, and produces effective, visible, entertaining results very quickly.

Python is described as easy, and on some levels it is, but Greenfoot’s way of laying out code and colouring the blocks makes it straightforward to understand and read, and the braces indicate clearly where code blocks begin and end, and the Greenfoot environment makes it much easier than standard Java to work in.

So we’ll continue with Greenfoot for a little longer, looking at the same constructs – if statements, loops etc – as we have in Python, and I’ll investigate the possibility of a simple editor that will help us create programs easily without panicking over how complex it is.

Oh, and I might investigate Processing further as well – as I understand it, that also uses Java, and is also very visual, enabling students to see and visualise the results of their code much more easily.  That, as I see it, is the most useful and efficient way for them to learn, rather than plugging in lots of text-based code.  They’re only 14/15 year olds, after all.




It’s getting to the point where I need to make a decision how I’m going to proceed in  September.  I think it’s fairly straightforward to declare that I intend to use Scratch/BYOB to introduce various programming topics, as it’s straightforward to put the code together and the user can focus on structure without worrying too much about typos, syntax etc.

Then I feel I need to move onto a “proper” typed up language, and that’s where I hit the problem.

So far this summer I’ve been dabbling in all sorts of things.  I’ve tried Small Basic, Python and Java mainly, Java being both through Greenfoot and Processing.

Small Basic concerns me because I discovered that it seems to overthink – when I tried adding strings together, because each string consisted of what it recognised as integers, it added them as integers.  I wonder what else it has up its sleeves, and I also feel concerned about teaching a Microsoft-specific language.

Python seems much more straightforward, and I like the way you can work quickly and easily from the command line as well as writing programs.  Getting a basic program up and running is really fast and simple.  There’s no fuss about declaring the type of variables and no worry about semi colons.  Instead, the fuss is moved to layout, and spaces/tabs.  There’s also the issue, though, of Python 2 v Python 3.   This seems to be a matter of preference, but some of my resources are for 2 and some for 3.  This isn’t necessarily a drawback; if I finish working through the resources for version 2, I should know enough to adapt the version 3 resources if necessary, but I’d like to stick to 2 for now because it’s what I’m using in the Udacity courses and with Google App Engine.  It also seems a very viable language to move forward with in either version.

Java has a wonderful tool in the form of Greenfoot, and Processing is another tool using Java as its base that is really quick and easy to start working with.  My reservation with Java comes in the form of not being so easy to work with straightforward input/output.  That’s possibly because I lack recent experience with it: I know I can use tools like Eclipse to write simple programs, but I find it horribly complex and would not like to introduce students to it as a learning tool when they first start programming!

Of the other tools, MIT App Inventor looks wonderful to use, and I would love to use it with key stage 3 who have already worked with Scratch, but again it’s graphic-based and I’m not sure how I would use it for the OCR GCSE computing tasks, which seem in the main heavily console based.  I don’t like the way I’m having to choose tools that are suitable for the assessment rather than tools that are best for learning, but maybe that’s something that will change as the qualification matures and newer assessments are added in.

So in summary, it looks like I need to consider Python 2 as first choice, while continuing to work through Greenfoot and Processing as these are my two favourite options.  As I’ll be using Scratch/BYOB at the start, while ensuring that other software is available on the school system, there is still flexibility for a while longer, and I would like to continue working in both Python and Java for my own purposes anyway.

The bottom line is that the real challenge when programming is knowing the structures to be used and how to use them efficiently, and in the end the choice of language matters little.  The main issue is to be able to form correct syntax and layout for the language.  As with everything, what you say is vital; the form you choose to say it in is less important.


Revisiting Greenfoot

I still want to see how Greenfoot can fit in with the OCR GCSE assessment tasks, so it’s time I learnt more about it.

So far I’ve learnt about adding methods, using IF statements and code blocks and listening for key presses.  We’ve also seen how to add objects to the world and how to have those objects removed by another object (eating a lettuce, for example).  The beauty of Greenfoot is that inheritance means the classes can be exactly as complex as they need to be – in the scenario I’m working on, there are various different animal types that all inherit from Animal, which inherits from Actor.  This means they all have the behaviours that are written for Actor, but also some that are written for Animal.  This means that methods/behaviours can be preprepared and inherited from a superclass, to be used without the learner needing to create them or understand how they work, and these have been dealing with things like removing an object when it is eaten.

Turtle game with bugs and counter

Turtle game with bugs and counter

Now it starts getting much more interesting.  We’ve taken the basic game of turtles moving around and eating lettuces, while being chased by snakes, added a variable to count the number of lettuces eaten and end the game at a set number of points and now we’ve added sound.   Then comes getting objects to talk to each other.

We add a new animal class, a Bug, whose code is mostly copied from the snake as we want it to move by itself.  We add code to the turtle telling it how to eat the bug and add to the score.  Then we need to tell the turtle that when it eats a bug we want another bug to appear in the world somewhere random.  This means we have to learn how to create a new bug, obtain the reference to the world and pass the bug reference to that world to make it appear somewhere random.  This produces an interesting new ability, that of creating objects on the fly.

The next job is to add a counter.  At this point in learning the code for a counter object is given, which is another good way of protecting the learner: sometimes you want them to be able to add and use a new class without having to create it, and in this case it’s as simple as copying the code from a text file and pasting it into the new empty class.  We can then use that class by adding it to the world and calling its methods without worrying how they’re implemented, although the curious can always take a look.

The turtle needs to be able to access the counter, and so we learn about constructor methods, and how to pass the world’s counter reference to the turtle.  At this point we also see how to add objects to the world object using code rather than by placing it manually.

A few adjustments to the point scoring process leaves a complete playable game.

In this session (videos 11-16 from Mik’s blog) a lot has been covered, from the simple steps needed to add sound effects to the game to some massive concepts involving references and object interactions, and on the way we’ve seen a couple of ways that the learner can be helped to focus on the concepts they need to learn rather than getting bogged down in details they just don’t need yet.

I still don’t know how to use Greenfoot for the sort of tasks needed for OCR GCSE computing yet, but I’m left far more optimistic that there will indeed be a way, as well as admiring the way that Greenfoot helps the student understand, from easy to access code documentation through layout tools to code completion.


Greenfoot part 2

turtle game with snakes and lettuces

Turtle game with snakes and lettuces

I’m still progressing with the Greenfoot videos, and my turtle game has now developed to the point where I control the turtle who eats the lettuces, while the snakes move randomly around and eat the turtle.

The code is still straightforward, although I’m already using constructs like If statements, sensing keyboard input, generating random numbers and moving my code into functions called from the Act method rather than writing a very long Act method – I like the way that good code practice is encouraged from the start.  In the same way, documentation via comments is encouraged.

Turtle code stage 2

Turtle code stage 2

Greenfoot definitely has a more grown-up feel than most of the other things I’ve looked at so far, while still being game-based.  The game so far is already open to many variations, both in graphics and in behaviour, even at this early stage.

What I’ll be interested to see is the point where the code can be used more generally; the GCSE syllabus covers many of the basic code constructs, but not generally to use them in a games context.  Indeed, for most of the assessment tasks a GUI is not necessary, and they could be built to use a console.  If Greenfoot gets easily to the point where it can be used for more procedural stuff as well, then it would be a good choice, but if that’s a direction it doesn’t move in very easily, then my impression is that it would be difficult to use it at GCSE level (although of course Java itself could easily be used, I would imagine).  For a computer club, however, it would be great.  And here we come to the argument between teaching things that are useful and/or interesting and things that will get a qualification!

Michael Kölling also has teacher commentary videos on his site, giving tips and advice to teachers who are introducing the concepts to their students, and these have some very good ideas.  I think at this stage the problem can be to keep students focused on what they can do, and developing and practising that, rather than thinking about what they would like to do, and attempting things they’re not up to yet.

Indeed, that’s my problem at the moment as well, in all these different programs!

Michael does make a point of showing how to access the documentation of a class as he goes through his tutorials, emphasising that it’s more important to know how to find information that you need than to actually have it in your memory.  I thoroughly agree with that principle: learning how to learn is the most important skill that someone can learn, because once they know the key to that, they can do anything else with it.


Introducing Greenfoot (Java)

I’ve looked at drag and drop code options, and I’ve looked at proper typed code options; this time I’m going to look at something that bridges the gap between the two.

Greenfoot is produced by the University of Kent, and provides a gentle introduction to Java via a system focused towards graphics – a grown up version of Scratch, almost, with its sprites.  The user is writing real Java, but in a very structured environment.

Java is an Object-Oriented language: this means that you create classes (categories) of objects, which can do certain things, and you can create sub-classes of those classes, which either extend or change the abilities of the parent class.  For example, when I first learned OOP (object-oriented programming) we learnt using frogs, little creatures who could move and jump.  We developed those into hoverfrogs (who could also hover in the air) and scared hover frogs (who could hover but only to a certain height).   So subclasses are developed from their superclasses and can do everything they can do (they inherit the ability to do these things) and can do their own special things as well.  This means that you can reuse code, instead of writing everything from scratch.

Greenfoot main screen

Greenfoot main screen

The Greenfoot site has a few tutorials to get you started with the basics, but to really get to grips with it I recommend Michael Kölling’s blog, which contains a series of videos that take you through step by step.

The Greenfoot screen has two areas: there is the world itself, and the list of classes that make up the world.  Two essential classes exist – World and Actor classes.  World classes contain the sorts of methods that a world in general needs to respond to; the world you wish to use in your program is created as a subclass of World, and has its own settings, including size and graphic.  The other important class is the Actor class.  This has its own methods, and any object you wish to place in the world inherits those methods as well as having its own.

simple greenfoot code

Simple Greenfoot code

Here we have the World, from which we have TurtleWorld, the world that we are running at the moment.  For the Actor, we have the original Actor class, then an  Animal class, then a Turtle class.  The Animal can do everything an Actor can, plus a few extra things such as tell whether it’s at the edge of the world, and the Turtle can do anything else that we design it to.

The code editor is reached by right-clicking on a class, and I found the colour coding in this editor incredibly useful: it really makes nested statements clear, and there is a code helper as well, accessed by starting to type a method then using CTRL[space] to see possibilities.

The first few lessons get as far as making the turtle move randomly onscreen and turn when it reaches an edge.  This leads on to making a simple game.

greenfoot class methods

Inherited methods can be easily found

Greenfoot is a gentle way to introduce a beginner to the idea of classes and inheritance, and writing methods for classes.  The actor class contains the method act(), which is an empty method.  This method must be defined in each class you wish to use in your world, and pressing the Run button on the scenario calls the act() method repeatedly on every single object in the world.  This leads neatly to the prospect of creating different objects, telling them how to act and putting them into the world together to see what happens.  So far in my world I have turtles who move and turn and eat any lettuces they come across and lettuces which just sit waiting to be eaten.

greenfoot code completer

Greenfoot code completer

The teaching materials for Greenfoot seem very good quality, and the projects on the website indicate that it has many possibilities and is an excellent way to introduce object-oriented programming, but after an initial session with it I still feel I need to learn a lot more before doing what I want to do with it rather than just playing with the techniques I’ve learned, and I’m not sure yet how it would fit in with the GCSE computing curriculum.

It does, of course, have the advantage that it uses a proper professional programming language that is also easily portable between platforms (you’re not tied to Windows, unlike Small Basic), and it has lots of really useful features that make it easy to understand and start using for those new to programming.

More to come, then, on Greenfoot!