
Experiences Using Go as a Teaching Language with Young Programmers - soheilhy
https://groups.google.com/forum/#!msg/golang-nuts/FIRSDBehb3g/BFiHYVNCwzUJ
======
krat0sprakhar
I think the usefulness of `go fmt` cannot be discredited here. I had a brief
stint of teaching a few school children programming in Python and initially
the most confusing thing for them was the indentation. While it was easy for
me to see that this statement would not be executed since its outside the for-
loop, they had trouble grasping why that statement was running just once.

~~~
_yosefk
How much time it took them to get it vs the time it takes to learn the
somewhat more elaborate incantations you need to spell a loop in Go? I recall
that dealing with parse errors, the easiest error for experienced programmers,
was REALLY depressing at 17.

~~~
nulltype
Can you give an example of those elaborate incantations? Parse errors are not
the greatest, but they removed the most common error I have seen among people
learning to program which is forgetting the semicolons.

~~~
_yosefk
Well, compare Python's:

for i in range(10):

...with Go's:

for i:=0; i<10; i++ { }

An experienced programmer might have an opinion about these syntaxes but he
can certainly handle both effortlessly. However, when I first saw for loops
using syntax similar to Go's, I could not, for a long while, remember exactly
what I have to type, and of course the compiler errors along the lines of
"expecting some gibberish after some other gibberish" didn't help at all - and
_not knowing that they aren 't supposed to help_ hurt, because I stared at
them, trying to decipher them, instead of guessing that I got it wrong and
looking up the loop syntax.

Now if you think about it, Python's incantation is very close to English ("for
i in range 10" instead of "for every in the range of numbers up to 10" \- you
omit some words and you add 3 punctuation characters but it's close.) Go's
incantation, if you try to read it, makes little sense ("for i assigned to
equal 0; i less than 10; i plus plus [or i equals i plus 1]".) You mention i 3
times which is weird, because beginners actually intuitively expect DRY code
(hence Java's AssWiper bill = new AssWiper [and I'm quoting from a toilet door
in a CS lab] felt very weird to me for a long while.) You have those
semicolons in the middle, and you're supposed to remember the order of these 3
parts - init, compare, increment.

I mean, it wasn't a huge trauma but I felt dumb for quite some hours until I
got it.

(Note that i:=0 and then a while loop incrementing i are _not_ nearly as
arbitrary because you compose it out of sensible primitives. A Cish for loop
on the other hand feels like one big blob of syntax which came out of nowhere.
Of course once you memorize it, it's vastly more readable than a while loop
because you pattern-match it and you translate it to "for every i from 0 to
10", and you _assume_ that nobody fiddles with i midway through the loop;
whereas if you see a while loop, you need to scan all of it because you will
suspect that i is being fiddled with in some non-trivial way.)

Also - omitting some parts of the for loop results in syntax which is fairly
crazy actually, if you read it out loud. Like for ; i<10; i++ - what's a
semicolon doing after the word for?!

~~~
jerf
Three-element for loops are the exception. The modal Go for loop is

    
    
        for idx, elem := range someSlice {
        }
    

Sometimes with idx replaced by _.

(Or at least, that's the modal for loop if you're doing it right.)

I wish I could make

    
    
        for x := range someSlice {
    

default to iterating on values rather than indexes... I do have rather a lot
of

    
    
        for _, val := range someSlice {
    

but, meh.

Personally I'd unhesitatingly introduce that version and pull out the three-
element version once someone needs it. People should learn value-based
iteration as the default. I have to admit when I'm doing an interview and I
see someone pull out the 3-element for loop in a language that does value-
based iteration, I mentally dock a point for choosing a dangerous construct
when an _easier_ , safer construct is readily available.

(Before someone jumps up and yells, I readily admit... no, _advocate for_...
Python's

    
    
        for idx, value in enumerate(something):
    

when available. I really don't like the 3-element for loop.)

~~~
_yosefk
Well, yeah, but if you want to iterate over integer ranges, don't you use the
for ;; {} form? (If not why is that form even there?) I'd expect the TFA's
Mandelbrot set example to need iterating over integer ranges (while most code
I'd actually write myself would iterate over elements of sequences.)

All I'm saying is, it's a lot of syntax to inhale, there are plenty of kinds
of for loop. _I_ certainly don't mind, and I'd be happy enough with "the modal
for loop" being DRY and compact. I just recall that my former self had trouble
memorizing grammar cases. Python's for loop always does for value in sequence,
so there's less syntax.

~~~
laumars
_> Well, yeah, but if you want to iterate over integer ranges, don't you use
the for ;; {} form? (If not why is that form even there?)_

for range _does_ iterate over integer arrays / slices. The reason the C-style
for loop exists is because sometimes you don't want to iterate the entire
stack. eg

    
    
        // iterate half the stack:
        for i := 0; i < len(slice) / 2; i++ {}
    
        // iterate with a stepping:
        for i := 0; i < len(slice); i+=2 {}
    
        // iterate from a different starting position:
        for i := 5; i < len(slice); i++ {}
    
        // reverse iteration:
        for i := len(slice)-1; i>=0; i-- {}

~~~
infogulch
Slicing is free and can be done inline, so your first and third examples can
be changed to the range syntax:

    
    
        // iterate half the stack:
        for i := range slice[:len(slice)/2] {}
        
        // iterate from a different starting position:
        for i := range slice[5:] {}
    

That still leaves stepping and reverse, but I've found those are relatively
rare, especially compared to the other two.

~~~
laumars
Ooops, just seen this comment. Yes, you're right, your slice techniques do
make a lot more sense than my examples.

------
keypusher
I'm a bit skeptical, as the author seems to be comparing to languages which
are rarely used for teaching children. Comparing "go run" to makefiles, for
instance, indicates that Go might be easier to teach that C, which isn't
saying much. If the author was previously using a different language and it
took the children 30 minutes to complete a simple task which now takes only 20
minutes with Go, that sounds great but perhaps there are other languages even
better suited to teaching where they would pick it up in 5 minutes.
Specifically, most of the points raised in favor of Go could be applied to
Python, which seems to be the most common teaching language right now. I would
be interested to know if there are reasons Go is a _better_ teaching language
than Python.

~~~
aaron-lebo
Python is a much bigger language than Go. Metaclasses, decorators, list
comprehensions. I could list feature after feature. Granted, some of these are
rather advanced features, but their very existence only adds complexity.

Go, because it is so (even overly) simple works really well in this domain.
It's also nice because with type deduction it feels dynamic, but it still has
some very C-ish features. You could easily go "up" to Python or "down" to C
from Go. Even after years of Python programming, there's a lot of concepts
from low-level languages which you never touch.

~~~
pcwalton
In place of metaclasses and decorators, Go has some combination of "go
generate", the reflect module, magic anonymous structure embedding, and
structure field tags, all of which add up to a good deal of complexity and
none of which Python has. Similar story with list comprehensions vs. Go's
magic builtin for loop syntaxes.

I think Go probably does have simpler semantics overall than Python does, but
not by that much.

------
_ak
Honestly, I'm not surprised. As Robert Griesemer, one of the core Go team
members, confirmed the other week in his GopherCon talk "The Evolution of Go",
Go inherited a lot of concepts from Oberon. Oberon is from the Wirth family of
languages, which are generally regarded as good teaching languages. He aptly
described Go as using C tokens, but having an Oberon structure.

------
schmichael
Glad to hear $GOPATH wasn't an issue for students. I think it's more an issue
for experienced programmers who already have a personal preference for
directory layout, project structure, and where things get installed on their
system.

I've actually gone the other way: storing all my source in $GOPATH-esque trees
as it turns out to work pretty well!

------
coolsunglasses
Potentially of interest is my coauthor's article, "Teaching Haskell to a 10
year old"

[https://superginbaby.wordpress.com/2015/04/08/teaching-
haske...](https://superginbaby.wordpress.com/2015/04/08/teaching-haskell-
to-a-10-year-old-day-1/)

------
zphds
Those kids must be really smart. I still have co-workers who can't get the
$GOPATH foo right. :(

~~~
schmichael
Force them to read this:
[http://golang.org/doc/code.html](http://golang.org/doc/code.html)

I know it's unfortunately long, but I have yet to find someone who has read it
and is still confused about $GOPATH.

~~~
toufka
Part of it is just understanding how to set up the $GOPATH. Understanding its
structure is one thing, but actually getting the 'go' to read the right
directory on OSX vs Ubuntu vs other systems depending on your shell (and
version of go?) and over old installations, can be a very confusing way to
start using the language.

------
pekk
What would really be useful would be a genuinely critical study that allows a
"post mortem" of what Go could have done better to support new programmers. If
all we ever do is toot our own horns, nothing really gets better.

~~~
mratzloff
I imagine it's useful on its own for educators.

------
haosdent
I have to said: Python should be better as the first language.

~~~
_ak
Why?

~~~
jimmaswell
I'd say it's a great learning introduction because it gets directly to the
point of executing one line after another with uncluttered syntax and no
boilerplate.

