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.
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.
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.
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?!
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.)
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.
Right, you do use the C-style for loop for numeric iteration.
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.
> 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-- {}
"Well, yeah, but if you want to iterate over integer ranges, don't you use the for ;; {} form?"
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.
I think (2) in Python is a clear winner over Go's C-style for loops, which are pretty bad all around: they're hard to understand for beginners, they're verbose, they make it easy to get boundary conditions wrong (especially with unsigned types!), etc. etc.
I found it easy enough to just compare the for loop syntax to its equivalent while loop at that stage. Plus once you've seen "for (int i = 0, i < 10, i++)" a few times it's easy to remember the structure, and then deduce which part does what - initializing happens once before, the middle part is the condition, the last part happens every time at the end. I don't see why it would be a big deal. Beginners in compsci classes seem to do fine with it.
We had a few programmers back at a previous job that used the "grasp" editor because it highlighted not just loops but control structures. I would occasionally use it to help make sense of some complex legacy code, but as day to day editor I found it lacking. I do like the concept.
I like the concept in theory, but the execution (just looking at some of the screenshots on the site) looks poorly done. The interface is unbelieveably cluttered and hairy. I don't think I could code in that at all. :/
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.
> I would be interested to know if there are reasons Go is a better teaching language than Python.
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.
The biggest one of his points which doesn't apply to Python is static typing. The trouble is that the drawbacks and the benefits of both static and dynamic typing are almost invisible in small programs. So you might say types help kids develop their reasoning or that the lack of static types helps them get up to speed more quickly and it would sound plausible in both cases... The fact is that for toy programs it hardly matters.
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.
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.
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.
> it took the children 30 minutes to complete a simple task which now takes only 20
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.
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.
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!
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.
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.
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.