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.