Experiences using Go as a Teaching Language with Young Programmers

Hello Gophers,

I'd like to describe my experiences using Go as a first programming language for a group of young programmers.
I know that there has already been some discussion on the list about this, see:
https://groups.google.com/forum/#!searchin/golang-nuts/teaching/golang-nuts/Jp6SBtec4bI/7jyh-ImaVxsJ
and
https://groups.google.com/forum/#!searchin/golang-nuts/teaching/golang-nuts/ewJpIYNXSvs/oWQh9XCahdsJ
but this has mainly focused on university students, or at least adults. See also Audrey Lim's
presentation at GopherCon about her experiences learning Go.
https://www.youtube.com/watch?v=fZh8uCInEfw

Maarten Koopmans has also recently asked for suggestions to help his son.
https://groups.google.com/forum/#!topic/golang-nuts/HSrF2tavElk
This is the first question I have seen that directly relates to teaching children.
My situation was similar to Maarten's. I had 12 eleven-year-old school children. Over the course of the last 7 weeks of the school year, about 12-13 hours in total, I managed to teach them just enough Go so they could write a mandelbrot generator. But,critically, they were able to understand the code.[1]

And what I found was: Go is not only a good teaching language, it's an excellent one for first time programmers, including children. I want to try and outline the Go features that really stand out when you have young programmers and why I think we've ended up here.

The first feature that helps is Go's left to right syntax. If you are eleven this intuitively makes sense because Go reads in a natural way. This becomes very apparent if you ask the children what they think a particular line means.

Secondly, Go has a small set of keywords. If you are child this turns out to be important because it seems like there's not a lot to learn. They can (initially) re-frame the problem of learning to program into "What do these words mean, and how do I use them?" Now the problem looks to be tractable to them.

Thirdly, go fmt is a huge help on a number of levels. It's a confidence boost to a child if they know that they can just type a program in and not worry about the exact formatting, knowing that the editor, via go fmt, will fix that for them. Over time they learn what the go fmt style is and just start doing this naturally.

Go fmt by its nature makes everyone's code look the same; this has an interesting side effect. When (not if) they spontaneously start helping each other, and they start comparing a program that works to one that does not, they are not looking at the formatting, they are focused on the logic. They actually compare the order of the steps in each program to find the differences and fix the problems. Go fmt shortens the mental leap you need to do this, without it this process may not have arisen as quickly as it did and would have required a much larger mental leap to see though the formatting differences. So go fmt as it turns out is actually an aid to learning and understanding. It lowers the barriers a child needs to understand a program. My conclusion from this is that eleven-year-olds need go fmt for the same reasons we do.

Fourthly, the go tool and the workspace. The go tool makes things very easy for young programmers to get started. Once they learn that all they need to do is use 'go run' to run their program they never ask how to run any program again. I only had to show them this two or three times.I just cannot imagine doing this with either makefiles or a string of command line switches. This is so simple that children just get it.

The workspace also helps. Simply knowing that they have to put their code under $GOPATH/src for it to work helps because it forces everyone to do the same thing. The children don't have to worry about the program not building because it (or a dependency)is in the wrong place.

When I started this, I thought that the children would stand a good chance of being able to use Go. But there were a few areas that I thought might prove problematic when I tried to explain them to the children.

Types are an interesting case. I thought this might be a really a hard concept for the children to grasp because it is fairly abstract. Most of the usual teaching languages used with children are "typeless"for this reason. But exactly the opposite was true. The children just got it. They only had to make the mistake of trying to assign an int to a string once or twice to realise that the compiler won't let them do this. The compilers static checking really helps here, because it stops the children and tells them there's a problem here.

But of course, having types also helped.The children had to reason about them when they first declared the variable. They would talk about what they wanted a variable for and then pick the type they needed. In a very subtle way this extended their logical thinking abilities.

I used Atom and a command line to teach the children, rather than an IDE. I was concerned that the lack of a UI and "Run button" might be a problem for the children. But they proved me wrong. Provided they have a syntax colouring editor, with go fmt integration, and they are shown what commands they need to build/run their program it's not an issue. Using the command line really wasn't a problem. Similarly they didn't need a debugger. When their programs went wrong they just went back to the editor changed it, rebuilt it and tried it again. The edit/build/run cycle is so quick they just didn't need a debugger. If anything having to use a debugger would have slowed them down. But this may, in part, be due to the smaller size of the projects they were creating.

Marking blocks with braces also wasn't a problem for the children. The children just never questioned it. Perhaps partly because go fmt also sets to the indentation to match. Or perhaps it’s because they have never programmed before they had no preconceptions about the presence or absence of braces. At the minute its not clear to me which case is true for the children. When they did miss a brace they soon learned to decipher the compiler error message a look to see where they had missed a brace or two.

What do I conclude from all of this? I don't think the Go team ever intended Go the be a good teaching language, but by a happy accident we seem to have both a good system programming and a good teaching language. A rare feat indeed. The only thing I can put this down to is the languages design process itself. Rejecting more than was kept and above all keeping things simple and orthogonal - both the language and the tools - has paid off in a way we might not had predicted.

As both Russ Cox and Andrew Gerrand pointed out at GopherCon this year we as a community must
not lose sight of these original goals as the language moves forward. If we do we might be risking the programmers of tomorrow as well as today!

Lastly if anyone else has tried teaching Go to first time programmer, especially children, I'd really like to hear what your experience has been.

I already have plans to teach another larger group over a longer time period from September.


Regards
Owen


[1] If any one is interested in the details of exactly how I managed this and the approach I took please drop me a email as the explanation may be somewhat off topic for the list.

Thank you Owen for sharing your experience. I really appreciate it as I also hope to teach some kids to program.

This is really great!

I'm very interested in the specifics as well, i.e. syllabus, what were the problems children had, what were easy, how difficult programs did they manage to comprehend, were pointers problematic etc. And I think it's fine to post the whole thing in the mailing list, I suspect others would be interested as well, and I think the specifics are definitely on topic. Unless you have other reasons for not in that case you can directly send it to me :)

+ Egon

I'm also interesting in this topic.  As I know, most computer language which was designed for children often let children make things easily. Like draw by a 'turtle', drag a icon or picture to let it move.  But in Golang, it lack such functions.  I'm wonder how to motivate children to use Go to do something interesting.

I don't usually +1 on a thread, but yes please expand on your methodology and anything else you'd like to share. I personally would like to see a world in which there were more "makers", and teaching code to children is a great way to increase the chances that citizens of the future will be participating more the the "making" of the things they commonly use.

I've been using Go to teach programming to my eleven-year-old son.

Hello Everyone,

Okay so as a few people have asked "How did I do it?" I'll try and explain....Apologises if this gets  a little off topic for the list.

Essentially I used a pattern based bottom up approach, with each stage building on the last one.

So we started with Hello World. Not for hello world itself, though they get a sense of achievement from printing this, but to show them how to edit/build/run a program.

Next we looked a numbers, so ints (*) to do simple sums (+. -. * and / operations) with small'ish numbers (<1K).

Next we looked at strings, with a simple program to print their name and age.

I think it is important to say that at this point there where no variables in the programs. Everything was static. I was just trying to get them used to typing code and beginning to understand little bits of it. So showing them how to print with fmt.Print and fmt.Println and reinforcing the edit/build/run cycle is more important at this stage. At this stage I'd showed them the pattern to print to the terminal.

Then we did variables, for both numbers and strings. I used a pattern approach to teach them this. So they had three patterns. Declarations in the form of "var variable-name variable-type", assignment in the form "variable-name = variable-value" and then the usage which is just the variable name. And yes, everything is long hand - there is no := operator. You can't use that until you understand what you are short-cutting. Also you want to make the types explicit so that they think about these. Kids with good maths skills will quickly see that variables are like unknowns in maths. Others you need to take a little more time with, before they see that the computer will substitute the variable value, when they use the variable name. I introduced this with a version of the strings program that used variables to hold their name and age.

Then we looked keyboard input so we can set the value of the variables at runtime. For this I wrote a simple wrapper around go's stdin stream handling. fmt.Scanf is fine in the stdlib, but it'll behave in an unexpected way if you feed it invalid input i.e. strings when its expecting ints etc. The behaviour is correct, but its not very encouraging if you are a child. The alternative I used was to wrap a read buffer around the stdin stream in a function (in a new package) without showing them the internals. That gave them a simple "Read{Number, String}FromKeyboard" function they could just use. To explain how that function worked I'd have to introduce interfaces, pointers, pointer receivers and streams which isn't appropriate at this stage. I wanted then to focus on using input to set variables. Not worry about how the input magic worked.

Then they did if and if-else statements again with patterns. So the if pattern became "if condition { true-statement-block }". I deliberately didn't show them the initializer block form to keep things simple. At this point they can start to write something "useful" so I got them to write a simple "quiz" that picked two random numbers, a and b, (between 1 and 12) and asked them to type in the answer to a * b. Then print out congrats, or bad luck depending on their answer. I had to take time with conditions, to be clear that the answer can only be true or false. So sometimes you need encourage them to "rephrase" the question. Also "==" took a little while to settle in, just because they hasn't see it before.

The last area they looked at was loops in the simplest form of "for condition { loop-body }". They used this to extend the previous program so that the program asked them a different question each time until they got the correct answer.

Once you have variables, if tests and loops you have enough knowledge to draw a mandelbrot plot. You only need 3 loops and an if test to do it. So I wrote a skeleton program that used the go SDL bindings to open the window and do the graphics parts, but left the calculation bits out. I needed to show them a little bit about screen coordinates (origin is top left, Y axis is down etc) vs. set coordinates so they can work out the scaling calculations. The pupils then had the follow the comments I left in the program to do the calculation.

I know this might whole approach might sound overly simplistic. But to get an eleven year old to this point will really stretch their ability to logically reason and problem solve. Sometimes we as adults forget just how much we know and take for granted.

Also I'm not trying to teach them idomatic go at this stage, or every language feature. That misses the point I think. What I was trying to do was to encourage then, and spark their curiosity, and interest. You want to remove as many barriers as you can at this stage. Once they stop thinking about what an if test does a how to write a loop or declare a variable you can start to building towards this.

Other more general tips if anyone else is trying this:

* Aim high, so pick something you think bright kids can do, then go a little bit further. Even I didn't think they would mange the mandelbrot plot when I started.
* Give them a goal, in this case they had the mandelbrot plot as goal from day one, that they can aim for to motivate them.
* Give them something fun or unusual, or something they ask about as the goal.
* Go slow, use little short lessons and build upon previous concepts.
* Go in a logical order. By this I mean don't aim for a http server until you can explain every concept that you need to use the stdlib code and have them understand as well. Start with the absolute basics and work upwards.
* Don't spoon feed them. By this I mean you can give then a complete program for the first two or three times. Once they get these working challenge them to extend them in some simple way. So print their friends name and age as well as theirs. Then as you go froward start to give them programs that are more and more incomplete and get them to fill in the blanks.

Owen

(*) I'm going to add floats into this in September as "float64" threw them when they saw it in the last lesson. The kept asking what the "64" meant.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Owen,

Picking up on one point in this....

Motivating the kids was not a problem at all. Really you only have to ask them if they want to learn to program. They love to learn new things to they'll naturally say yes.

Owen

Picking up on one of Egon's points...

Pointers I haven't talked about yet, and I don't plan to for quite a while. Before I can go anywhere near pointers, I'd need to talk to them about how their Go program looks in memory (in terms of a process). So I'd need to about what a stack is and why we have one and why it has a limited size, which a fundamentally a hardware restriction.(*). Then we can talk about the heap. So if your data type won't fit on the stack you have to put in on the heap. But the only way to access that data is from the stack. So we have to have something on the stack that can reference the data in the heap. That's what a pointer is. 

Which is a bit much for a 11-year-old to take in.

At the minute none of their programs have needed pointers. So they've not encountered this. The one exception is the mandelbrot skeleton that I wrote and I tucked all of the magic away in some functions that they just had to use.

In terms of where they got stuck. Initially learning to use the variable name when they meant the variables value was hard. Using float64's was hard, but entirely because of the type name. They thought the "64" was something related to the value. Other than that, if you take it slow enough and give them the practice and support they'll start to get it.

(*) And if we are going to talk about stacks, we need to talk about stack frames, which means I have to have talked about functions before this point, and the concept of variable scope before I talk about functions.

Owen

No, I've not compared teaching go vs teaching python.

I did consider doing this in python. It's quite popular with kids - partly due to the Raspberry Pi Foundation - who do things mostly in Scratch or Python. So it seems to be fairly popular in schools.

But I rejected Python for much the same reasons as the Go team. I've been bitten (hard) by defining blocks with white space. Editor support or not, these are hard to spot and I think pretty frustrating if you are a kid. From their point of view why would a space make any difference? So I can appreciate your experiences.

I've also been bitten by Python's PYTHONPATH variable, picking up the wrong set of modules to import, or plain just not finding them at all. Which again just seems like an extra hurdle for the kids to jump over.

I wanted to teach in a statically typed language. As I've said elsewhere in this thread, types are an important concept that new programmers need to learn. We can also pick up a lot of beginner mistakes early with the compiler that Python's interpreter defers until execution time. It also has the happy side effect of forcing you to reason about your program by asking "what do I want this variable for?" which by implication forces you to consider the variables type.

On the plus side, there are a lot more libraries, programs, tutorials etc out there for python compared to Go. But this will resolve itself over time.

From my point of view the one big thing we seem to be missing in the Go world is a _simple_ SDL based games package. Enough to help the kids to start writing simple 2D games. Things like tetris, pacman, space invaders, or platform games, horizontal (or vertical) scrollers, that I can use to teach the kids with. We don't really have a direct equivalent of PyGame (yet)

If I'm ever in a position to compare the two languages with two similar groups, I'll report back to the list.

Owen

[Sorry. I forgot to cc'ing to the list.]
Hi

In theory everything is spread over 1 hour sessions once a week. I say in theory, because in practice I had to run a couple of extra 1 hour sessions, to get the kids though the material before the end of the school term.

I always had a teacher in the room with me. So they maintained the order, but mostly that wasn't needed. Monitoring progress I can spot form just looking over their shoulder, or they'll ask me a question.

Owen

Hi Owen,

Hi Paul,

In terms of English not being their first language, some of the Go docs have been translated. So this might give you a starting point rather than trying to do this in English.

https://github.com/golang/go/wiki/NonEnglish#chinese---%E4%B8%AD%E6%96%87

What age range is 6th grade? That's going to be different form Year 6 here in the UK, which is 10-11 year olds. If they are a lot older (13 or so) they you should be able to extend my experiment a bit in terms what you can teach. Things like functions, packages, arrays and maps and structs should be possible by then.

Yes, whatever you do you have to make this as interactive and practical as possible. They will only learn if you get them to physically program as much as possible. Roughly speaking my experience suggests this needs to be 50% or more of the total time available.

One thing I did try was to get the students to help each other. Some of them will be better than others, so use them to help you. My experience was that they really liked having the extra responsibility and the others were just as happy to learn from them.

You also need to keep this fun. So give them a fun target to aim at. The chat program would work, just keep in mind that you have a lot of steps to get though to get to that point. I think you need to think about a set of fun sub-goals that they can aim at en-route. Ideally smaller things that would be useful on their own.

And yes, I'd be really keen to hear the result of your experience.

Good luck

Owen

Hi Dan,

When I first read this, I thought "No way, I don't get it." But now I've thought about it a lot more I can see what you are getting at. Yes, a pointer is just a way to share something.

So I need to have a think about how I might be able to introduce the concept. Introducing the concept early would also open the door to talking about pointer receivers and hence interfaces.

My one worry would be if I introduce it this way, and the kids then start Googling around they'll see the traditional memory view of a pointer. But as a pre-cursor to the traditional memory view this looks like an approach worth trying.

Thanks for the suggestion.

Owen

If I had to explain it, I think I'd say that variables are stored in memory (no stack and heap, just memory locations) and a pointer is a variable that indicates and refers to a location in memory. Maybe draw a picture with the memory divided in cells/locations with an arrow of one variable pointing to the location of the other. There should be no need to introduce stack and heap, you can have pointers to heap locations and pointers to stack locations and the language guarantees that the pointers will always be valid.

I've usually explained pointers in terms of a byte array.