[ANN] go koans

[sdeg...@8thlight.com]

In the vein of programming koans in other languages, I have written go koans for Go1 which is intended to be fun, somewhat humorous, and educational about how to use Go.

https://github.com/sdegutis/go-koans

Bear in mind, it is incomplete right now, notably missing goroutines, channels, errors, and panics.

If anyone has ideas for improvements, please let me know, or fork it and submit a pull request if you want to.

-Steven

[roger peppe]

perhaps i've got the wrong end of the stick, but i think
it would be nice if these were
a) gofmted
b) compilable.

[sdeg...@8thlight.com]

Can you be more specific about why it didn't compile? That would be helpful. It compiles fine for me when I run 'go test' locally. You might have to run 'go get github.com/sdegutis/assert' first.

And thanks for the advice about gofmt. Just ran it and it looks slightly nicer now. The changes are pushed up.

-Steven

On Friday, March 16, 2012 10:26:30 AM UTC-5, rog wrote:

[Peter Kleiweg]

When I run 'go test', all I get is one error, and it stops. Should a
test report all errors?
Or am I missing the point?

[sdeg...@8thlight.com]

The way programming koans traditionally work is that you run the tests, get one error, find the line that's causing the error, fix it, run the tests again to see the next error, and repeat the process until all the koans are complete and you have sufficient understanding of how to use the language.

Since it's annoying to have to switch back and forth between the test files and the terminal to run "go test", I've created a tool called "fswatch" for users of Mac OS X like myself, which will run whatever command you give it if it notices a change in the watched directory. The README in the go-koans project explains how to use this tool with go-koans. Similar ones probably exist for linux, but I don't know what they're called, but I bet they use inotify.

-Steven

[roger peppe]

On 16 March 2012 15:57, <sdeg...@8thlight.com> wrote:
> The way programming koans traditionally work is that you run the tests, get
> one error, find the line that's causing the error, fix it, run the tests
> again to see the next error, and repeat the process until all the koans are
> complete and you have sufficient understanding of how to use the language.

ah, that's my wrong end of the stick... thanks for, um, enlightening me.

[KarateCode]

> Bear in mind, it is incomplete right now, notably missing goroutines,
> channels, errors, and panics.

I must have gone through after you added some things, because I found
a panics koan and a channel/goroutine koan. I think the koan with the
channel would be too much of a leap for beginners. Maybe add an
example before it with a little more hand-holding? I was also
thinking it may be nice to find a way to show that the 'range' keyword
can also be used with channels.

I would love it if you also added a new section that deals with
Readers and Writers. It's hard to spend much time in the standard
library without running into them. It was one of my biggest hurdles
when learning go. Every language I've every dealt with in the past
deals primarily with fully loaded strings. Go seems to, wherever
possible, pipe data around. It was hard for me to wrap my head around
at first. I think a beginner would benefit from not only learning
how, but also learning why Go focuses on Readers and Writers.

Other than that, very well done! I think koans are a great learning
tool!

[sdeg...@8thlight.com]

Thanks for the feedback.

You're right, the channel/goroutine part does seem to dive into the deep end too quickly. But I can't think of another, more gentle way to show off either goroutines or channels independently of each other and in an isolated, small example.

Also, how would you show off io.Reader and io.Writer? The only isolated ways I can think of are with bytes.Buffer but that's kind of lame as a showcase, although very useful in testing.

-Steven

[KarateCode]

> But I can't think of another, more gentle way to show off
> either goroutines or channels independently of each other and in an
> isolated, small example.

I think something as simple as this would suffice:

func passBack(channel chan string) {
channel <- "from a different process"
channel <- "share values across goroutines"
}

func aboutConcurrencyIntro() {
ch := make(chan string)

go passBack(ch) // put 'go' before any function call to send it off
on it's own goroutine

assert(<-ch == __string__) // coming back...
assert(<-ch == __string__) // the purpose of a channel is to...

}



> Also, how would you show off io.Reader and io.Writer? The only isolated
> ways I can think of are with bytes.Buffer but that's kind of lame as a
> showcase, although very useful in testing.

This one may be a little more challenging. I like how Rob Pike is
always saying to visualize it like Unix pipes. I think using io.Copy
to pipe something to standard out is a trivial yet easy to understand
example. But it may be hard use in the context of your koans where
everything comes down to a simple assert between two objects. Another
idea is to use os.Open which returns a Reader for a file. If you made
an object with a Write function on it that simply writes to a string,
then you could assert against the resulting string. For a bigger
challenge (I believe "A Tour of Go" did this), you could make the
student write a function the accepts a reader and a writer. The
function must read characters off the reader, apply some sort of
simple or ridiculous character filter, and write the results to the
writer.

[sdeg...@8thlight.com]

Good ideas. I added some more koans and changed a few, I'm curious what you think:

The 4 commits on March 26 have the relevant changes:

https://github.com/sdegutis/go-koans/commits/master

-Steven