Go as the first programming language for students
Translation of a story about the learning experience of programming a group of schoolchildren using the Go language. The original text in the mailing list here
( original photo )
Hi Gophers,
I would like to describe my experience of using Go as the first programming language for a group of young programmers. I know that there have already been posts on this topic ( here and here ), but they mainly concerned the education of students, or at least adults. There is also a presentation on Audrey Lim's GopherCon about her first programming experience and Go.
Also recently, Martin Koopmans asked for advice on this topic for his son.
And this is the first post of this kind that I found related directly to the education of children.
')
My situation was similar to that of Martin. I had a group of twelve 11-year-old students. During the entire 7-week course, about 12-13 hours, I was able to train them Go sufficiently so that they could write a Mandelbrot fractal generator. But, much more importantly, they understood and understood the code.
What I learned from this experience is that Go is not only a good language for learning, but also great for complete programming beginners, including children. I will try to outline the aspects of Go that are really important when you are dealing with young programmers, and how I came to these conclusions.
The first aspect that helped is syntax, read from left to right. If you are eleven, then it clings intuitively, because the Go code reads naturally like text. This becomes very obvious when you ask the children what they think about this or that line of code.
Second, there are few keywords in Go. If you are a child, this becomes important, because it creates the feeling that there is not much to learn. Initially, it allows children to transform the problem of learning programming in “What do these words mean and how to use them?”. After that, the problem seems to be solved.
Third, go fmt turned out to be an indispensable assistant at once on many points. This is a strong increase in confidence for children, when they know that they can just write code and not worry about the correct formatting, knowing that the editor, using go fmt, equalizes the code for them. After a while they get used to Go style and just start writing themselves in a natural way too.
Go fmt, by its nature, leads any code to the same style, and it had an interesting side effect. When (but not if) children spontaneously started helping each other, and compared a program that works, with a program that does not work, they did not look at the formatting, but focused on logic. They actually compared the sequence of steps in each program to find differences and correct the problem. Go fmt reduces the mental effort required for this — without it, this process would take more time, since it would take more of the mental effort spent on sneaking through differences in formatting. So go fmt turned out to be an actual assistant in learning and understanding. It reduced barriers for children to understand the code. My conclusion from all this is that 11-year-olds need a go fmt for the same reasons that we need it.
Fourth, this is the go tool and the workspace. Go tool greatly simplifies the process for young programmers. As soon as they find out that all they need is to run the “go run”, they never ask how to start another program. I showed them literally 2 or 3 times. I just cannot imagine this using Makefiles or command line parameters. It's so easy that the kids just grabbed it instantly.
Workspace also helped. Just knowing that it was enough for them to put the code in $ GOPATH / src for everything to work, it helped a lot, as it forced everyone to do it. Children did not have to face the situation that their program does not start because it (or dependencies) is in the wrong place.
When I started this project, I thought that children would have good chances to quickly master Go. But still there were several topics that in my opinion could be problematic for an explanation.
An interesting case here are the data types. I thought that for children it would be a really difficult concept to understand, because it is rather abstracted. For this reason, “typeless” programming languages ​​are most often used for teaching programming. But it was exactly the opposite. Children just grabbed it at times. It was enough for them to make a mistake once or twice with assigning a string to a numeric variable to understand that the compiler would not allow them to do this. The static type checking of the compiler really helped, because she stopped the children and said that there was a problem.
But, of course, the types also really helped. Children had to justify which type they chose when they declared a variable the first time. They talked about why they want one or another variable and then choose the type they want. Almost imperceptible to them, it expanded their logical thinking abilities.
Instead of an IDE, I used the Atom editor and the command line to teach children. I was worried that the lack of a UI and a Start button could be a problem for children. But they proved me wrong. Having an editor with syntax highlighting, integration with go fmt, and knowing how to build / run their programs, this was not a problem at all. Using the command line has also not become a problem. Also, they did not need a debugger. When their programs did something wrong, they simply returned to the editor, changed the code, reassembled and tried again. The fix / build / run cycle in Go is so fast that they simply didn't need a debugger. Using a debugger every time would have hindered them. Although this may be partly due to the small size of the projects they wrote.
The braces for marking blocks were not a problem for children either. Children simply did not ask about it. Perhaps this is partly because go fmt always corrected the alignment of the parentheses. And perhaps because they had never programmed before, and therefore had no preconceived beliefs about the presence or absence of curly braces. At the moment I myself did not fully understand that there is a root cause for children. When they forgot to put a bracket, they very quickly memorized a compiler error that reported this, and looked for where they missed the bracket.
What conclusions can I draw from this? I don’t think that the Go authors team has ever positioned the language as a good language for learning from scratch, but by luck, we seem to have a good system language, and a good language for learning programming. A rare feat, of course. The only thing I can explain is the process of language design itself. Throwing out more than leaving, and keeping in the main priority simplicity and orthogonality - both language and tulling - it paid off in full, and with such a side that we hadn’t even imagined from the beginning.
As Russ Cox and Andrew Gerrand spoke at the GopherCon conference this year, we, as a community, should not lose sight of these initial principles of Go, as language develops. If we forget about them, we risk to ruin the lives of both future programmers and ourselves.
And finally, if someone else tried Go, as the first programming language, especially for children, I will be very happy to hear your experience.
I also have plans to train a large group for a longer period, starting this September.
Respectfully,
Owen.
( original photo )
Hi Gophers,
I would like to describe my experience of using Go as the first programming language for a group of young programmers. I know that there have already been posts on this topic ( here and here ), but they mainly concerned the education of students, or at least adults. There is also a presentation on Audrey Lim's GopherCon about her first programming experience and Go.
Also recently, Martin Koopmans asked for advice on this topic for his son.
And this is the first post of this kind that I found related directly to the education of children.
')
My situation was similar to that of Martin. I had a group of twelve 11-year-old students. During the entire 7-week course, about 12-13 hours, I was able to train them Go sufficiently so that they could write a Mandelbrot fractal generator. But, much more importantly, they understood and understood the code.
What I learned from this experience is that Go is not only a good language for learning, but also great for complete programming beginners, including children. I will try to outline the aspects of Go that are really important when you are dealing with young programmers, and how I came to these conclusions.
The first aspect that helped is syntax, read from left to right. If you are eleven, then it clings intuitively, because the Go code reads naturally like text. This becomes very obvious when you ask the children what they think about this or that line of code.
Second, there are few keywords in Go. If you are a child, this becomes important, because it creates the feeling that there is not much to learn. Initially, it allows children to transform the problem of learning programming in “What do these words mean and how to use them?”. After that, the problem seems to be solved.
Third, go fmt turned out to be an indispensable assistant at once on many points. This is a strong increase in confidence for children, when they know that they can just write code and not worry about the correct formatting, knowing that the editor, using go fmt, equalizes the code for them. After a while they get used to Go style and just start writing themselves in a natural way too.
Go fmt, by its nature, leads any code to the same style, and it had an interesting side effect. When (but not if) children spontaneously started helping each other, and compared a program that works, with a program that does not work, they did not look at the formatting, but focused on logic. They actually compared the sequence of steps in each program to find differences and correct the problem. Go fmt reduces the mental effort required for this — without it, this process would take more time, since it would take more of the mental effort spent on sneaking through differences in formatting. So go fmt turned out to be an actual assistant in learning and understanding. It reduced barriers for children to understand the code. My conclusion from all this is that 11-year-olds need a go fmt for the same reasons that we need it.
Fourth, this is the go tool and the workspace. Go tool greatly simplifies the process for young programmers. As soon as they find out that all they need is to run the “go run”, they never ask how to start another program. I showed them literally 2 or 3 times. I just cannot imagine this using Makefiles or command line parameters. It's so easy that the kids just grabbed it instantly.
Workspace also helped. Just knowing that it was enough for them to put the code in $ GOPATH / src for everything to work, it helped a lot, as it forced everyone to do it. Children did not have to face the situation that their program does not start because it (or dependencies) is in the wrong place.
When I started this project, I thought that children would have good chances to quickly master Go. But still there were several topics that in my opinion could be problematic for an explanation.
An interesting case here are the data types. I thought that for children it would be a really difficult concept to understand, because it is rather abstracted. For this reason, “typeless” programming languages ​​are most often used for teaching programming. But it was exactly the opposite. Children just grabbed it at times. It was enough for them to make a mistake once or twice with assigning a string to a numeric variable to understand that the compiler would not allow them to do this. The static type checking of the compiler really helped, because she stopped the children and said that there was a problem.
But, of course, the types also really helped. Children had to justify which type they chose when they declared a variable the first time. They talked about why they want one or another variable and then choose the type they want. Almost imperceptible to them, it expanded their logical thinking abilities.
Instead of an IDE, I used the Atom editor and the command line to teach children. I was worried that the lack of a UI and a Start button could be a problem for children. But they proved me wrong. Having an editor with syntax highlighting, integration with go fmt, and knowing how to build / run their programs, this was not a problem at all. Using the command line has also not become a problem. Also, they did not need a debugger. When their programs did something wrong, they simply returned to the editor, changed the code, reassembled and tried again. The fix / build / run cycle in Go is so fast that they simply didn't need a debugger. Using a debugger every time would have hindered them. Although this may be partly due to the small size of the projects they wrote.
The braces for marking blocks were not a problem for children either. Children simply did not ask about it. Perhaps this is partly because go fmt always corrected the alignment of the parentheses. And perhaps because they had never programmed before, and therefore had no preconceived beliefs about the presence or absence of curly braces. At the moment I myself did not fully understand that there is a root cause for children. When they forgot to put a bracket, they very quickly memorized a compiler error that reported this, and looked for where they missed the bracket.
What conclusions can I draw from this? I don’t think that the Go authors team has ever positioned the language as a good language for learning from scratch, but by luck, we seem to have a good system language, and a good language for learning programming. A rare feat, of course. The only thing I can explain is the process of language design itself. Throwing out more than leaving, and keeping in the main priority simplicity and orthogonality - both language and tulling - it paid off in full, and with such a side that we hadn’t even imagined from the beginning.
As Russ Cox and Andrew Gerrand spoke at the GopherCon conference this year, we, as a community, should not lose sight of these initial principles of Go, as language develops. If we forget about them, we risk to ruin the lives of both future programmers and ourselves.
And finally, if someone else tried Go, as the first programming language, especially for children, I will be very happy to hear your experience.
I also have plans to train a large group for a longer period, starting this September.
Respectfully,
Owen.
Source: https://habr.com/ru/post/264643/
All Articles