Practice English Speaking&Listening with: Teaching Kids To Code

Difficulty: 0

>> 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.

The Description of Teaching Kids To Code