A colleague bemoaned how Project Euler was far too mathy and not at all practical. He felt there needed to be a more useful version, like display a number of items on a web page. I mentioned that this sounded like a koan.

Koans? What are They?

Koans were first put together by EdgeCase as a series of exercises that used a test framework and heavily commented code to teach Ruby. They cover several topics; array manipulation, functions, exceptions, classes, etc. Many other language evangelists have attempted to use the Koan format to teach there favorite language. And for this, they are very well suited.

I loved the Ruby Koans. I enjoyed the Haskell Koans. However as far as they go teaching you how to use a real framework to do real work, they were anemic. But I still think there are some great things to learn from them. Especially if I want to teach some frameworks.

So, what are the principles if Koans and how can they be used to teach long-form ideas? And can I pick on an existing set of koans as either good or bad examples? Can I back up what I was talking about with real code?

Principles of Koans

Koans run quickly. They run until they find the next lesson, usually a broken test. There test errors should give you a file name and a line number. The lines near the error are filled with comments explaining what you need to know to make the next test pass.

Koans lead you down the path. Each step builds on what you’ve learned and adds a new twist. While they break in to larger topics in each file, then slowly build out the knowledge of that test.

Koans I’ve run, the good and the bad.

Speedy turn around is where the Haskell koans fell flat for me. First off, I had to compile several files before I found out if my solutions were correct. They weren’t, but I had to use the number of trues an falses output and the number of assertions made to figure out where I had made my mistake. I got it wrong, and you’re not helping! I would drop the Literate Haskell file type and just use the runhaskell command to fail the first file before the next even gets compiled.

One of the things I liked about the ruby koans was their simulation of TDD to guide the completion of a project. Yeah, it was a simple project, but still. It was me writing actual code to do actual work. It spiced up the exercise and was a nice island of diversion on the ‘path to enlightenment.’

Halfway There

I taught WPF for a company class. The project I had them work on was an iTunes clone. Each week I’d ask for them to get a little bit more done. Each week, I’d put a little more business logic up for them to use in their app. But I don’t scale. Don’t get me wrong, I’m not the best WPF guy in the world. I might even be average. But I want to share what I know.

What keeps my project from being a Koan is a lack if automated tests. If I had some test failures mixed in that would guide them to success, then we’d have a winner. But I couldn’t use plain old NUnit to handle it. I’d need to deal with leading them in steps to writing code that I can eventually compile against. It is possible that the C# 5 compiler as a service will help smooth this out some for my WPF example, but reflection can help. As for Matt’s world, odds are he will get this for free by using a dynamic language like Python or JavaScript.

A successful take on this was the Rails for Zombies project. So what Matt Swanson and I are proposing isn’t anything new. It just takes time and planning, trying to make everything build out in an order that allows learning and several small projects to actually live and breath.