>> KOLLING: Good afternoon. Thank you for coming and thank you for having me here. My
name is Michael Kolling, I work at the University of Kent in Canterbury, England, in the southeast
corner of England. Pretty much opposite of channel tunnel so we can--can look over to
France from there. And I've only--I've only arrived here in the US last night so I'm still
out of my time zone, but I think this--this time isn't too bad. I, if--if it hits me in
the middle of my talk and I suddenly get tired, I'll just drag on to the end. I want to talk
to you today about the topic, that's on the screen there already, "Teaching Kids to Code."
So I want to talk a bit about what we do to--to teach programming to kids. In this case, happens
to be Java and that was maybe one of the things to talk about it as well, but that's a good
or a bad thing. I will spend my time doing--doing mostly software demo. So I--I--I will show
you a system called Greenfoot that we--that we use for teaching and first of all, I give
you an introduction, you know, the typical few slides with the background and then I
do the demo and then I sort of skip all that. And I do mostly demo and I sprinkle the--what
I would have said in the introduction somewhere in the middle and maybe that's a little more
interesting to see. The thing about software demos is they are--you've probably seen many
of them and there are very different kinds of demos and I have recently seen a magic
trick that reminded me a lot of the way how many software demos are and I thought I'll--I
want to show you today just to--you'll--you'll understand what I mean. The trick is a very
classic trick, classic magic show. It's the cut the rope trick. So, you probably have
all seen that at some stage. You have a standard bit of rope and I'm going to cut it in half
and then I put a knot in it and then I'll do my magic and then the knot is gone and
it's all in one piece again. So that--that--that's, you know, fairly standard bit of magic. So
here's my bit of rope, I'm going to cut it now, has anyone got a pair of scissors on
them? Well, if--if you don't, it doesn't matter because I'm well prepared I've got one that
I made earlier. Here, so I've cut it already and I'm going to put my knot in it now which
I'm not sure I'll be good at. But, well, it doesn't matter because I got one that I prepared
earlier. And now I'm going to make this knot disappear. So I'm--just count to three and
then it will go away and we have one bit of rope again--one, two--well, it doesn't matter
because I've got one that I prepared earlier, and here we are and that is pretty much how
many software demos are going that I've seen at many conferences and then at the end, you
wonder, you know, what--what--what you've just seen. So I--I hope that I--that I'm not
going to do this and--but really show you everything from--from start to finish so that
you get an impression of what this system really is. So, the system itself is called
Greenfoot. Greenfoot is a system--it's essentially a programming environment that we have built
for, explicitly for teaching programming to young beginners. We had another system before--well,
it's still around, we built another environment for teaching. Previously, it was called BlueJ.
That was aimed essentially at entry level university students. So we--we had talked
for--for some years already in the context of BlueJ about teaching programming to beginners.
And in our mind, that was always first semester university. But the truth is that first semester
university now is not the first contact of kids with programming anymore. And we thought
if we are--if we are--we've said for a long time that we want to do, you know, teach programming
in a sort of padagogicly valuable way and--and good way right from the start. And the start
is just not entry level university anymore. The start in fact and--where we lose them
already is at school level. So, we thought that if we're serious about, you know, doing
it--doing it in a--in a good way from the beginning, we really have to go a bit lower
than that. And there's one big, big difference between teaching at university level and teaching
at school level, and that is if you teach at a university which--it's my--my day job,
you have a much easier time because you have a captive audience. You know, they can't run
away. They--they--they have made a choice to be there and I'm--what I'm inclined to
say they want to be there, that's not always literally true but in some sense of the--of
the word it is. You know, they--no one forced them to be there, well, maybe their parents
did, but by and large, you know, they are interested. Whereas if you are one of the
school teachers, you know, the poor people having to stand there with 15 year olds, 80%
of the students before you even start talking have already decided that they are not interested.
And so that is one of the main differences is that a lot of--of what I am going to show
you is about generating motivation, of being--being--being sort of fun, being--being engaging so to draw
them in. So what we are trying to do here is two things at the same time, we're trying
to teach them something valuable but at the same time, we're trying to do something that
they actually want to do, to draw them in. I'll just go ahead and show you some things
and then I'll give you a bit more background later. So what I've got here on my screen
at the moment is Greenfoot and I'm just opening another project here. So here for example,
I have an existing Greenfoot scenario we call them, a scenario is essentially one--one project.
Where I have here on my right, a representation of the classes that are involved in this project
and here are what we call--what we call the world. So I have already written some classes
here, so these are Java classes that I implemented, and the first thing we typically do is not
to write code but to start interacting with classes. So when I have a class here, I can
click on it and I get a pop-up menu with a few operations and one is to instantiate this
class so I can create a new outlet here, of this class interactively. And when I do this,
I can place my object into the world. And when I have an object in the world, I can
click on the object and I can see all the public methods of this object and I can now
interactively invoke this--these methods. So I can tell this wombat for example, to
move. A wombat by the way is an Australian animal. I don't know whether you've seen it,
a funny looking, you know, looks something like this, you know, [INDISTINCT] my drawing
abilities. So I can now interactively invoke these methods, I can tell it to move, I can
tell it to turn left, I can make it move again. I can also invoke methods with parameters.
For example here, I've got a set direction methods--method and I can type in some constant
and--and then it will move in the direction. I can have method results. So for example
here, [INDISTINCT] move method checks whether the wombat can forward at the moment. So if
I invoke this, hit returns true and if I move him here to the edge of the screen and then
ask, "Can you move forward now?" It says, "False." So what--what's happening here--well
and--another one thing I should show you maybe, I can crate more of them. So I can create
now as many wombats as I want. So what is happening here is that I can introduce valuable
concepts of--of objects orientation in a very concrete way. So I can talk about the relationship
of classes to objects, you know, that in class, from a class, you can create many objects,
I can later get to the relationship to the source code as well. I can--I can essentially
tell the story that we can communicate with objects by invoking their method--their methods.
So every object has a set of operations that you can perform on them, I can talk about
parameters and return values and so I can, first of all, introduce the fundamental concepts
of object orientation before I have to talk about where the curly brackets go into semi
colon [INDISTINCT]. So it's a--it's a, sort of top-down pedagogical approach, where we
don't start with all the little, you know, tedious detail, but we start with the big
picture. I can then click the X button which makes them all go forward at the moment, every
actor class, so Greenfoot gives you a framework that consists of a world and multiple actors.
Every actor, by definition here, has an X method and if I click the act button, that
act method of every actor in the world gets called. And so if I click the run button,
run is just a loop around act, so if I do this they all just run around. I can then
put leaves into the world and if I put some of those in and I put some wombats around,
if they run around they go, oops, they go around and eat the leaves. And I can then
look at them and say, "Okay. How many leaves have you eaten?" And I can, you know, so I
can discuss in this context the concepts of--of state, you know, that there's different objects
and they have a different state and one has so many leaves and--and I can interrogate
them about this. I have here an example that I may use at the beginning of--of teaching.
So typically, I--I said just--in my remark about--about demonstrations, I said I wouldn't
hide anything. So I'll just show you briefly how to really start from scratch because here
I've got an example already where I prepared something which is the normal way a teacher
would start teaching but just for--for you, I'll--I'll also show you how it works to create
a scenario from scratch although in a teaching situation; that wouldn't be the first thing
I would be doing, you know, in a teaching situation, that comes a little later. So I'm
creating here a new--I don't know if--I selected open instead new. That won't work--so I want
to create a new scenario, and I can close this one. So this is what I get when I create
a scenario from scratch, I always have the world in the [INDISTINCT] classes, they are
part of the Green--Greenfoot framework and then I can create a subclass of the world
and I call it, let's see, I've got some backgrounds here. Got a [INDISTINCT] of bricks so I just
call it wall, I'll make a brick wall. And so in addition to the typical, you know, name
of a class that the Java class has always have. In Greenfoot, there's also an image
associated with every class you create. And if now I create this and compile it, there's
my world. And if I open the source code, it gets the skeleton automatically and there's
no path in there. This is where the interesting thing, this is the side--size and the resolution.
So let's say I want a one pixel resolution and I make it 400 by 200, oops, 202. Well
its good enough as well. So here's my--well that's a bit big. And then I can create a
subclass of an actor. And let's say I create a bug and you see here, it's a library of
images. You can select any of the images that come bundled with the statement or--here with
the browse button, you can use any image that you have anywhere in your file systems. So
for students, that means that very quickly they, you know, have pictures of their teachers
running around and getting eaten by monsters and that--that goes always really quickly.
So I can see some of it here. There are some, you know, that's a good enough image. So,
once I compile this I can immediately instantiate a bug and put it in here because the default
skeleton that every new class gets is syntacticly correct so it compiles even though there's
no real code here. And then I can do things such as set location. I've got a set location
method; I also have a get X and a get Y method and of course, if I use X and Y as it is then
it doesn't change anything. But if I now add a little bit to my current X location--X coordinate
and--and use that as my new location, if I put my bug in here again and now it crawls
across the screen. So very, very quickly by writing essentially two lines of code, one
here and one in the world, I can get any magic graphics onscreen. And that is very important,
that is just the--the--the motivator, you know, that we use to draw kids in this, to
get graphics and animation and then interaction very quickly on the screen. I can now add
something like, set location--set rotation is what I meant to write. And get the current
rotation plus a little bit, and if I soft change the location and the rotation at the
same time that is rolling across the screen. So it gets--it's--it's fairly easy to get
an animation on screen. In a teaching situation as I said, typically you would prepare little
bit and--and preparing means that you can choose essentially the level of, of abstraction
you want to expose to your students. So this--this is an example that might be typical example
as the very first thing that you do with students. This is one example that I've used a number
of times with 14-15 year olds, where I've got a crab and you can start by telling them
about classes and objects and we can instantiate the crab, and if I click run, nothing happens.
And then we open the source code and check why nothing happens and of course there's--because
there's no code in here and then I can just write move, and if I write move in to this
and instantiate it again, it moves across the screen. And then I can write things such
as turn five--five degrees, and if I do this, it runs in a circle. And the move and turn
methods that I've just shown come from the animal class which means as a teacher, by
providing super classes of the classes where the students actually work, you can decide
essentially the API, the complexity of the API you want to give them. And so if on the
day I think they are not ready to--to discuss parameters then I'll write my method as I've
done with the move where it just moves at constant a bit forward. I could have done
the same with the turn of course, to just turn a constant angle or if I want to discuss
parameters then I--I write my turn method so that I can discuss what a parameter is.
So this gives the teacher a good level of control over what--what level of complexity
you want to expose. And for students writing this stuff, then fairly quickly there's a
question, "Okay. What are the--what are the methods I've got available?" And we can look
at the animal class and by default, here this one opens in documentation view, you can switch
the editor here between the source code and the documentation. And if I prepare that,
as a teacher, I just switch it to the documentation so that is this is what it will show me by
default. And I can see I've got here my move and turn method and there are some other ones
to check whether I'm at the edge of the world and--where I can eat something. So I can now
write code quite easily where I write if at world edge then I turn something and that
means now if I--if I run this now, I've got here, oops, I've got the wrong class selected--that
means that this will now run around and turn around when it hits. And then again of course,
one of the nice thing is--nice things is that once you've written that you can have many
objects and can have them running around. And then you can create new classes. So I
can say I want a new animal, oops, didn't mean to do that--new sub class is what I meant
to do. We can put in a worm and I've got a picture prepared already and if I compile
this, I can put these worms into the world and the crabs then like to eat worms and so
at the moment when they run over them, nothing happens at all but then I can write code here
that says, "if can see worm" so I can specify a class here that I'm looking for and if I
can see an object of that then I want to eat it. And if I do this now and I have a number
of worms here and I put a crab in, it's eating the worms. And fairly easily, you can also
put sound in. And so if I then--then do--there's a play sound method and I have a couple of
sound files prepared here. And if know the name of the sound file, it is very easy to
just play it. So, we can do that again, put my worms here, put a crab in and...
[pause] >> KOLLING: ...okay, he might get enough.
It's not very loud; it's a fairly soft sound but still. And--and, oh, one last thing I
should show you, we can keep our control fairly easily. I can ask the environment whether
a key is being pressed and every key has a name so I can just ask for the left arrow
key is pressed then... [pause]
>> KOLLING: ...hold the right one if the left one, let's say, I want to turn something a
bit to the left and otherwise, a bit to the right. And that's--that's--for beginners this--these
are sort of the nice discussions, you know, if you've shown them that you can turn and
then you point out, "Well they always turn right," you know, how do you make them turn
left and then they quite quickly get the idea, you know, negative numbers and then I, usually
when I do this in a teaching situation, I first get them to, get the crab to turn randomly,
sort of every--with a 10% chance or so it should turn a bit, you know? And then we get
a random number and if it's okay if you have a number, how can we now express the 10% chance
and you can get into nice discussions about some programming. But in this example here
now--what have I done? [pause]
>> KOLLING: I don't remember the names of my methods. That's what I've done. Well, I
can show you how to look this up. The Greenfoot API itself is a total of five classes. So
we--we tried very hard to keep it as small as possible. So there are only these five
classes, that is all there is and we can--I can print them on--on three normal pages of
paper and the method is called "is key down" not "key down." So, you see this is an integrated
environment where documentation is linked in. You can get fairly easily to the documentation
of the class and so now if I have the crab and I can run around, I can now control this
with my keys and can make it run around. And you can see--this very quickly gets into sort
of game-like scenario. So what we typically do, when I do sessions, sort of one day sessions,
is I--I often do sessions with school classes, just single day sessions where we take sort
of 15-year olds that have never programmed before to write a game within a day. And so
the next thing is we add some--some other lobsters of something there that then chase
the crabs which is fairly easy because the code is almost identical to the crab. So you
can do that very--very easily and then you can--have to run away from the lobsters and
try to get all the--all the worms before the lobsters get you and all that. What they typically
do is they--they very quickly come with their own ideas. So I have my sort of prepared story
line to build this game and at the end, just about--I--I always have them working in pairs,
it works very well if there's two of them together discussing it. Almost every pair
is doing something different and that is one of the really strong stories here of--of using
sort of graphical animations and games is they--they come with their own ideas, they
immediately get their own ideas. You know if you, as a very first exercise, get them
to print out the Fibonacci sequence or something like this, they might get there and that's--that's
the end of the story then, you know? It doesn't lend itself to suddenly come up at, "Oh. I
could also do this other sequence," you know? That just doesn't happen at that age. With--with
game like scenarios, you immediately get the reaction that they have things they want to
do, that they want to add. And that is very powerful because that changes ownership, it's
suddenly not--not your program anymore, it's theirs and that's--it's a very powerful thing.
What they all discover very quickly is that you can just change the image. So just by,
you know, setting the image here to something and then you can, I don't know, look through
there, make it an elephant and suddenly without changing any code at all, you have an elephant
running around. And of course that doesn't change anything, programmatically at all,
it's just a different image but suddenly they have killer sheep going around eating babies.
And--and suddenly they get really excited, you know? It's a very small thing, it is--technically
it doesn't really add anything but suddenly, because they see they can do things, you know,
and also things that you haven't told them, they get very much into this. The code you
write, because it's in Java, of course it can become as sophisticated as you like. It's
not only games. We--we often use games as sort of an early example but here it's--it's
just a simulation. So this is an ant simulation there--sorry--two anthills here and there's
ants running around and there's food sources and the--the behavior of the ants is actually
very primitive, they just run around randomly until they happen to run into some food and
when they find some food, they run back to the anthill and they leave drops of pheromones,
that's this whitish clouds here, you see there. And if they smell some pheromones, they just
turn away from the anthill and go on the direction and that's all. And so, if you have enough
of them you get this path forming behavior and there's no explicit code there to--to
form these paths. This is emergent behavior that comes just out of, you know, the grouping.
So what Greenfoot does is it gives you very--a very easy entrance to getting graphics on
screen and to make them move. And so every program that has as its output two dimensional
graphics is very, very easy to do. So game is--and one obvious answer but simulations
is another class of programs that works very well. And as you've seen, we don't have to
write any graphics code, you know? And when I just did this--you actually--when you--when
you program in Greenfoot, you--you program only the logical state of the object. So you
just set its X coordinate or its Y or its rotation or its image and the graphical animation
is automatically done by the environment. So there's--there's no graphics code to write.
So that is educationally really--real nice because that allows you to talk about the
important programming principles and not about details of--of producing graphics. For teaching
in schools, this is--this is really something that at the moment is very hard to do. Programming
in schools is, in the UK, probably worse than in the US. In the UK, there is a really dismal
situation where there is almost no real computing left in the compulsory curriculum in--in schools
at all. In the US, I don't know the details; my impression is that it's a little better
on average but also not everywhere. In--the only compulsory computing subject in the UK,
in high schools, is called ICT. That's Information and Communication Technology, and what they
do there is essentially learning to use Office, you know? They teach them Excel and they teach
them PowerPoint and the--the closest they come to programming is to write some macros
in Excel. So they make 14-year olds do tax--income tax calculations in Excel. And then they--they
are surprised why they're bored, you know? The--it's called ICT but colloquially, the
school kids all call it computing. They think that that is computing. In fact they think
that is computer science. And they come out of it knowing for sure that they hate computer
science. And--and they're well within their rights to hate it because it is awful, it's
just not computer science but they don't know that, you know? It's--they--so a bit later,
in the, sort of towards the end of their high school, in a part that's in England it's called
A levels, they can--they can choose subjects and one of the subjects they can choose is
computing where they do a bit of real programming. And a survey has just shown that the reason
why so very few students choose that is the experience with the ICT course because they
have seen that computing is boring. There was a survey about attitudes to--to IT and
computing recently and that has shown that there is a real serious image problem. Computing
is seen as boring, not intellectually challenging. There is a stereotype of, you know, these
geeks with thick glasses sitting in basements with a [INDISTINCT] next to the computer screen
never talking to anyone. And large groups of kids get turned off before they ever find
out what programming really is, you know? And programming in a--in any interesting sense,
isn't represented for most kids in the school curriculum at all. And so what we are trying
to do is to open a way how programming can be brought back into school. And the problem
of course is--one problem is that, you know, in modern programming systems, it's become
more complicated than it was in days when there was basic of, Pascal even. You know
that was a smaller entry hurdle. Now, there's a lot more infrastructure and teachers in
fact aren't well educated to do this and often have trouble doing this. So we want to bring
tools back that make it as easy to get started as it was with basic 20 years ago. But then
again, you know, when we started printing out a triangle of asterisk on the screen,
it was really exciting. Now that doesn't really excite kids anymore today. So we tried to
do something that--that looks a little more interesting but is as easy to--to get into
in your first few steps. I think teaching office automation tools to 14-year-olds that
boarder some child, now, that is--at that age, they should--they should be creative,
they should do things, they should invent stuff, they should build things, you know,
they should have their ideas and make them happen and that is, you know, what we need
to bring back. Most people I know who work in computer science have started--you know,
got in through programming because programming was exciting. And so I think programming is
a good way to get an interest in computer science. Most of the examples I've shown you
so far were these essentially bird's eye views of a world of actors that run around. It doesn't
have to be like this. There are other things you can do. I'll just very briefly show you
some examples. So here's a lift simulation, for example. So that's a side on view where,
you know, you have six floors and lifts going up and down and how you can then, you know,
right lift control algorithms or something like this or another example is just nothing
really very meaningful at all, just something to look at. It's just a net of dots hand [INDISTINCT]
if I grab one of those, I can drag them around. Now--and so, you can just--in examples like
these, the nice thing is that you can really concentrate on the logic of the movement and
don't really have to write the graphics code. There are some applications--because this
is not really--not a toy language, this is--because this is full Java, you can make it as complicated
as you like and there are uses of this--of Greenfoot in universities as well. I've got
a colleague who is using Greenfoot and agent modeling calls for writing where they develop
essentially AI algorithms for behavior of agents because, you know, you can--you can
put any algorithm in there that you want and the reason he's using this is just because
he's not interested in doing the graphics and you get the graphics for free essentially
here. You can then just concentrate on the logic and the Greenfoot Environment just does
the graphic animation for you. Another colleague of mine at the moment is working on developing
examples were the topic matter is chemistry where you have, you know, reactions of molecules
on screen where you don't learn only about programming but you learn something about
chemistry as well. So that's another possible level of learning where you can actually teach
something about the subject matter for which then you can manipulate through code as well.
What have we got here? And when we have the animated graphics and we have keyboard control
then very quickly, of course, we have game-like scenarios. So here, I have to land this bomb.
Okay, that wasn't--I have to land that very, very carefully. I'll try once more. So you
have to come down very slowly. Okay, I'll give it one last try. I have to concentrate
on landing. Okay, you can try after this talk and see if you can do any better. When you
actually get it done, there's a flag coming up which is, of course--a great student of
mine wrote that who is obviously Danish that's why it's this flag. But the reason I brought
this up is just to show you the sort of possibility how you can do--I now that blew up as well--how
you can do testing with this. Because you can instantiate, manually instantiate any
class and you can manually call any method, you can do very nice, very quick testing.
So as soon as you finish writing one method, now you can instantiate it and you can run
it and you can see what happens and debugging is almost implicit. Because a lot of the behaviors
is visual, you immediately see if it goes wrong. And so in this case, for example, I've
got my explosion here, which I can put into the road and then it does a bang but the one
thing I've done is I've written it so that when the explosion touches anything, that
thing explodes. So if I put any objects in here, let's say the flag, let's say I put
some flags in here and then I put an explosion somewhere on one side, I get this chain reaction
and I can just try this out. And this chain reaction isn't explicitly programmed it's
just the behavior of the explosion, and the code for that is actually quite simple. This
is--this is the code that does it, you know. When the explosion acts it just goes bigger
and smaller and then disappears but here it just says, you know, every time that an act--it
gets the--instead of indirect of overlapping objects, you know, that's a get interacting
objects and then now there's a field so I can essentially filter here to a certain class
and I'll say without having a filter it means I take any object that comes along. And then
I just go through them and I say if that object is not itself an explosion then I just put
an explosion where that object was and remove the object and that's it, you know, and that--you
get this now. So you can--this interaction gives you a lot possibility of trying things
out very, very quickly. So if you're a student developing something or if you're not a student
either because I do that a lot and, actually, it's quite good fun once you get started,
you can't--you don't have to complete a whole scenario before you see the first effects.
You know, you write one method and you put it in and you look at it, you know. That--it
goes--there is no test drivers to write or no complete application. Once you have a partial
thing going, that partial thing will go. The quality of the animation you can achieve is
good enough to actually look--so here, for example, there's a--there's a sort of--you
can--there's a lot of--this is actually the--using Greenfoot by example where I've seen most
software we use actually happening and you might have noticed that that's the same explosion
as I just had in previous one. There is a lot of possibility to just take classes from
existing things and put them over. So here, this is just the standard asteroids. So you
see that there is a--you know, the animation certainly is good enough that this looks like
something you can play. And so students can achieve something there that they can actually
show around. That is, we wanted to achieve the same sort of quality of code that you
can do with all those flash games that are now on websites. And from a motivational point
of view, showing it to others then is very important, it's very powerful. So one thing
we have done here is we've got an export possibility. We can export part of--as an application which
is essentially just a writing and executable dot file or we ca make a webpage out of it.
And let's say I put that on my desktop and export it and then it writes me a webpage
with an applet on it. And here I have then--this is what it generated. And so if I open this,
I get this is on a web browser and there is my game and I can play it here. And so, of
course, you know, from perspective of learning to program that doesn't really add very much
but as a--as a motivator, that changes a lot. The program--the problem with this generating
a web page, of course, is you still need a web server somewhere to make it public. If
you do this, you know, you have it now in a web browser on your own machine but you
still can't send the URL to your grandmother. So to solve that problem, we are just at the
moment working on building a web server, a public web server where anyone can just put
their stuff up there. So if I here do my export and there's a publish functionality and that's
at the moment still experimental. Actually, I should reset this and then put that bit
together so that I get a--get an image because if I do the export, I have my screen image
here and I can use this as my icon for my game and then I can give it a title. And if
I put my username and password in and export this, this now builds the same thing, the
applet and the webpage, but it puts it on a public web server which we have--which I
hope is up at the moment because there's people working on it right now. So if I go there,
this is now really live on the web and here is a page, which I should reload because I
had that up earlier. So, okay, I was--I just didn't--I didn't look at my dialogue. I reloaded
it because I noticed it isn't here because if it's recently added it should be the first
one here. That is ruined. That is ruined. Let's try that again. Yes, that's one--that's
essentially the same thing that I put on there earlier. So there is already another version
of this--of this scenario on there. Okay. Now it said complete, so if I go back to that
page and I reload this, there should be now our version on here. So this is the one we
just put on here. So this is--we think about this as something like YouTube for games,
for programming games. And so the idea is, first of all, that through this thing there's
a strong motivational thing because, of course, it has all the--all the sort of standard,
you know, social interaction stuff that they have nowadays with writings and leaving comments
and all that kind of thing. And people can really show around their work. And we have
sort of the hope that through this people might get interested in this through actually
playing the games so we'll have some games on--so, featured games at the top that are
actually sort of very nice looking and then links that show people what this all could
look like and how they, you know, [INDISTINCT] it in Greenfoot and change it.
>> [INDISTINCT] >> KOLLING: That asteroid thing?
>> Yes. >> KOLLING: That's the arrow keys and the
space bar. Turn your sound down. >> I already have.
>> KOLLING: Okay. So here the very thing I should maybe--I'm--I don't really want to
show you a lot more but may be as a last thing just to give you one other idea. One other
nice thing you can do, of course, is if you get live data somewhere. So here, for example,
if I click act it goes out to some weather server and gets actually real time weather
data. And so there's a--there's a whole number of things you can quite easily do. And there's
a question, of course, whether or not, you know, Java is the best language to use for
something like this. There are--well, it's a blessing and a curse at the--at the same
time, you know. Java clearly imposes a lower bound to how young the kids can be doing this.
Now, I've used Greenfoot with my own daughter who is eight--well, it started when she--she's
10 now--and that works with, sort of, sitting with her one on one and helping her out, you
know. I have to help her a lot with the syntax, you know, just the question of forgetting
brackets and things like this. At that age, it is really still a big hurdle. So it's clear
that at that age for a classroom situation that wouldn't work. That's too young. For
a sort of one-on-one situation it works. But it was also interesting that all the problems
with syntax she got the concepts really, really easily and really quickly. So with a different
language you could probably go lower down in age. We use this mostly sort of with kids
14 and upwards but then, of course, there is the good thing because Java is a--you know,
it's not a toy language it's a full language where everything you want to do is supported.
There is really no limit about how sophisticated you can make it and you can do really interesting
stuff at scales, you know, because there is--it's really just the standard Java compiler. So
you get all the benefits of having real language in there rather than a toy language but it's
trade-off. What we are trying to achieve here is to create a situation where the first contact with programming
can become really engaging and interesting, you know, where we have--so the two goals
in mind, we want to draw them into programming, we want to show them that this is something
that you can enjoy, that can be--that can be, you know, good and satisfying and at the
same time what we don't say openly is we actually want to teach them good programming principles.
So we want to discuss things such as classes and objects and separation of concepts and
the visualization of the classes and the object is important so that they can see, you know,
that there are separate objects and they interact and they can references to another end like
communicate by evoking each other's methods and permit a passing and all the--all the
important concepts and object under programming get automatically discussed. The other thing
that we are trying to do is we are trying to see the kids and the teachers both as target
groups. You know, teachers in--at school level are often overwhelmed with the complexity
and they don't really know how to teach well either. So what we're trying with Greenfoot
is to give a very clear guidance about, you know, what the concepts are that you should
be discussing because we tried to expose them explicitly in interface, you know, there are
classes, there are objects, there are methods and all the things we think you should talk
about, you know, are explicitly there in your face, so that that gives a structure about
what you--what you should cover. We're getting closer to the end of the time so I think I'll
stop here and just leave another few minutes for questions in case there are questions
but I'll stop my talking here--at that point. I think you were first.
>> Yes. What do you think of--I don't know if this is--don't know--what do you think
of Flash index as a teaching tool for writing games like this for kids?
>> KOLLING: I think from a--from a language point of view, you know, from a teaching point
of view Java is nicer than Flash. I'd rather teach Java because it represents some of the
concepts that are important to me much nicer than Flash does. From an--just performance
of the technology, Flash is clearly winning at the moment, you know. The--one of--well,
if you compare performance and startup time, for example, between applets and Flash, of
course, applets really has some catch up to do. Luckily at the moment, the story we are
hearing out of sun is that they're working on this, you know, improving them, sort of
use experience for using applets and that would be nice. There still is--applets are
still a pinpoint where, you know, you get different arrows and different browsers and
all the--you know, you all know some of the problems. So from a technology point of view,
Flash actually works better at the moment, from a pedagogical point of view Java is my
clear preference. There was a question there as well and Josh, I don't know. Do you want
to go to the microphone? >> Mine is really so I'll ask when my brother
comes up. So, how many lines of code, roughly speaking, in the asteroid's program?
>> KOLLING: That's about 200 lines of code. So that is something--the asteroids program
that is something that a total beginner can achieve after two or three months or so. So
it's not very far out there. As a teacher, I can write that in an hour and a half also,
you know. So that is--that's the other thing, as a--as a teacher, the scale and complexity
of supplying these examples is manageable, you know, for--in acceptable preparation time
and students, after a reasonable time of study, can get there. The teachers can write that
is important because often the way you start teaching, the early examples is sort of a
fill in the blanks exercise. You might give them the asteroids scenario almost done by
the rocket doesn't move, you know, and then the early examples can be too--could be to
just, you know, do the rocket movement and everything else is already there. Yes?
>> I have a few questions. Let's see, start with--could you go back to the crab worlds?
Do you still have that? So I want to make sure students try this very quickly and I
could download it and try it myself but I just like to know, what happens if try to
eat a worm and there's no worm there? >> KOLLING: It--well, we can look at the--this
is--so if I do this, you know, say, if I--if I do this here, which means it would eat a
worm at every step, right? >> Yes.
>> KOLLING: Right? >> Yes.
>> KOLLING: And I compile this. I put my crab in its elephant costume in here, nothing happens
at all. And the real odds, of course, is whatever the implementer of the animal class has written
there is what will happen. >> Okay.
>> KOLLING: What I happen to have written here is that I just ignore the fact. So here
in my each method, whereas my implementation of my eat method is here, I just see whether
there is an object at, you know, offset zero-zero from where I am, which means there is another
object of the given class of the worm class at my location and if there isn't I just don't
do anything. >> So actually I--what I was really wondering
is there an exception mechanism visible to the user?
>> KOLLING: It could be. So if I now decide to throw an exception here...
>> Yes. >> KOLLING: ...or if I call one of the API
methods that throws an exception, that is visible. So, you know, if I do this now. If
I don't ignore this now but I actually tried to remove now, I would expect this to give
me an exception and if I do this immediately this stuff pops up here.
>> Okay. >> KOLLING: And I get my exception.
>> So, my other questions are at a higher level. So you can save applications in random
as applets, very cool. Can you run Greenfoot itself as an applet?
>> KOLLING: No, currently we can't. >> Have you thought about it?
>> KOLLING: We thought about it. It is technically not easy and we decided at some stage that
it's not worth the trouble. I mean, it--that it's sort of more trouble than it's worth.
Part of that is that Greenfoot runs internally two virtual machines, one to run the user
code, essentially, and one to run the environment itself and there is communication going on.
And all that actually doing that in an applet, you run into all sorts of problems with the
security and so there would be so much fiddling necessary to make that work that I think--and
I don't see a strong enough benefit to actually justify that. So downloading it, running it
locally is--was--our judgment is it's probably the preference for most people anyway so that
I don't think it's a--as a cost-benefit payoff I don't think it comes out.
>> Okay. Fair enough. The thing I was wondering about--so this is--you're starting off introducing
kids to programming for the first time and it's an object-oriented language, which is--isn't
how I'm going to program, so I'm just wondering you have enough data of what happens--how
do they deal when they encounter a procedural language for the first time? Are they puzzled?
>> KOLLING: We have data from that not from Greenfoot and school age kids but we have
done--there is data that was done at a university level where something like 5 to 10 years ago
there was, in the computing education community, a big discussion about object orientation,
how to teach object orientation and when to teach object orientation and whether it should
be taught first. And many people have heard probably about the problem of the paradigm
shift going from a procedural to an object-oriented language. There are studies that there is
really--there really is a problem that way, you know, going from a--from a procedural
to an object-oriented language. And so, studies show that the other way around, there doesn't
seem to be this problem, you know. Going to procedural language from an object-oriented
one seems to be a lot easier than the other way around. So, we haven't done any studies
where people started at school age but I don't expect that to be a real problem.
>> Okay. Thanks a lot. >> So I guess the questions I wanted to ask
was the first one I see you doing a lot of things involving sub-classing actors but it
seems like you just set up the background with an image and the size and the granulation
and that's all you're doing with it. Is there kind of any functionality, say, to change
the background? >> KOLLING: Yes. Yes. That can all be done
programmatically as well. So the background can change, the image of the--well, if I--if
I open the end scenario again and just show you quickly the--it's maybe clearer to see
here with the actors but the same is true for the world. So here, for example, the pheromones
here are actors as well and the image of the pheromone is not loaded from an image file
but drawn dynamically at run time so that it actually just draws a circle with a certain
size and [INDISTINCT] and the image dynamically changes, you know. So the image of an actor
has an image but that can be loaded either from a file or you can draw it programmatically.
And, for example, the count here is also an actor, you know. There is--the some that are
here is the counter and that is just a transparent image where I'm writing some text onto a transparent
bit of image and that updates itself automatically. >> Okay, so...
>> KOLLING: So--and you can do the same to the background of the world.
>> Okay, let's see. What kinds of requirements are there to run this? Like, you obviously
need a compiler which means having the JDK. >> KOLLING: Yes, it requires JDK, Java5 or
later. >> Okay.
>> KOLLING: Okay. We have--sorry, we are running out of time. So, last question or is that...?
>> I just want to ask, would you--this all seem like they are running into or are also
working on [INDISTINCT]. >> KOLLING: Yes, the question was whether
we're also working on material lesson plans to go with this and the answer is yes. That
is, in fact at the moment, that is our main focus. The software at the moment is at a
stage where it's working unstable and it's all well and we are extending a little bit
but the--that is, in fact, the main thing that is needed next. They are--it's a little
bit already there, not very much but we are working on this at the moment and there will
be more available very soon. Okay, we are out of time. Thank you for coming.
