Experiences Using Go as a Teaching Language with Young Programmers
groups.google.com
groups.google.com
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?!
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.)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.
The reason why a more succinct form for numeric iteration isn't there is that Go has no generics, therefore no generic interfaces, therefore no Iterator interface, therefore no iterators. So Go had no choice but to build all syntaxes that look like iterators directly into the language.
Yes, but in general, needing that is the exception, not the rule.
Ironically, a great deal of those exceptions tend to arise when doing toy projects and teaching children, so, I'll grant a solid touche there. :)
"Python's for loop always does for value in sequence, so there's less syntax."
Well, in a straight-up contest, Go and Python actually sorta... tie, or very nearly. Go's for has four versions (by my count):
1. for x := range y {...}, value iteration
2. for init; cond; post {...}, the traditional 3-element for loop
3. for cond {...}, which is basically the while loop
4. for {...}, "loop forever"
the latter being something that is actually used with some frequency by server-like goroutines.In Python, that's:
1. for x in y
2. actually a bit of a pain, but for i, x in range(y) + break
usually covers it. (Go has break too, of course.)
3. while cond:
4. while True
Net-net, if Python wins, it's not by much. I will give it points for making value iteration the simpler, visibly-obvious preferred alternative.In the general "syntax to inhale", I gotta say Python is the clear loser. It's the clear loser due to being a featureful language that has evolved a lot over the decades, in a way that is generally to its advantage, but in this particular context, no, it's no contest. Python has way more syntax than Go. It is way easier to write idiomatic Python code that someone with 4 weeks of experience in Python will look at and not even know where to start searching the manual to find out what just happened (generator comprehensions in particular can be really sneaky). Go could be covered in its syntactic entirity in a well-paced high school semester.
I'm personally a bit ambivalent here. Python has been my goto recommendation for "teach new people with this" language for a good long time, but I am forced to admit that Go is potentially at least competitive, with the right resources created for it. It's a really different spin on the newbie experience, but it has a certain appeal. I'd probably stick with Python until those resources appear, though.
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-- {} // 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. func it(n int) []struct{} {
return make([]struct{}, n)
}
// ex. 1:
for range it(10) {
fmt.Println(".")
}
// ex. 2:
for i := range it(10) {
fmt.Println(i)
}The editor appears to live on as "jgrasp"
We had a hpux or solaris X-windows native version which lacked the button party bar.
Since its us Gov funded it would be nice if they posted the source.
I don't know if it is _better_, but Go has a number of programming concepts you don't see in Python:
- Static typing
- dealing with pointers and dereferencing
- building binaries vs. using an interpreter
- Non-class based OOP
I can see these being helpful to get under your belt sooner rather than later.
Go wouldn't be my first choice, but I found the write-up helpful. I'm predisposed to think interpreted languages like Python are "easier" for kids. Good to see something that shakes that up a bit.
EDIT: bullet points layout
As for struct-based OOP, why would you want to teach that?
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.
I think Go probably does have simpler semantics overall than Python does, but not by that much.
Not when you're just teaching programming to children. You stick with a subset of the language that makes sense for the age group you're teaching; the existence of features beyond that doesn't matter, because they won't come up.
I think children would do fine and learn stuff by doing machine language, and some nicely tactile binary input system. They'd take much longer to do anything they could do in 30 minutes in go though, which implies the metric is not so good.
I've actually gone the other way: storing all my source in $GOPATH-esque trees as it turns out to work pretty well!
https://superginbaby.wordpress.com/2015/04/08/teaching-haske...
I know it's unfortunately long, but I have yet to find someone who has read it and is still confused about $GOPATH.
https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...