Short Programs for Short Programmers

work safe

It seems some of my esteemed colleagues decided to have a “Blogging” contest. They have, therefore, pressured me in to posting a couple of blog entries. I hates them so.

I’m a regular at the Indianapolis Code and Coffee. If you’re local, join us at 7:00 am on Thursday! Korff and I started doing some Project Euler problems in Haskell this week. Matt Swanson made a comment about Euler being way focused on math and wanting Project Euler for “practical” things. His idea of practical was, as an example, displaying a list of items on a web page. Hrm… Reminds me of Ruby Koans or Rails for Zombies. I’ll get to that post in a few days.

I’ve done some of the Euler problems and they are really math oriented. The point of these exercises really is to think about math and the relationship of numbers. What a programmer can take from these exercises is focusing on algorithmic implementation and optimization. It is not that we solve it, but that we tweak and re tweak our implementation to be faster or more expressive. It is a great way to learn about a programming language in the small.

Koans are small guided steps. Where Project Euler expects a single number as an answer with out regard to HOW you got the answer, koans are all about the journey. They are usually language specific. They are a series of automated test failures that allow a conversation of learning similar to The Little Schemer. Again, koans are about learning small concepts a little at a time.

Katas are also about the journey. The problems that katas use are actually incidental. It isn’t important that I’m dealing with an incomplete simulation of a bowling game, or pricing some children’s books. It is about the things you do around the problem. Katas are about the red/green/refactor cycle.

All of these have their place and appeal to different people for different reasons. But they deal with software in the small. Like writing short stories, they teach you how to communicate more effectively. These lessons can be taken to larger structures, but they can also teach a kind of tunnel vision. A short story is not a novel and their structures are different. With that caveat out of the way, enjoy yourself. If you’re pressed for time, they can be great bite-sized puzzlers and exercises. They can also teach you to take care with the smallest parts of your code.



  1. Matt  •  Oct 15, 2011 @5:29 pm

    The Euler problems can also be good for messing with tdd. Write a test, because the right result is often easy for a human to define, or it’s the problem statement (red). Make it pass (green). At this point, it’s usually too slow, or sometimes you just want to see if there’s another interesting way to do it (refactor).

  2. Todd  •  Oct 16, 2011 @1:26 pm

    As someone who will probably soon have significantly more “free” time to play with, I’m interested in Koan & Kata.

    I’ll take a look at your links. Thanks.

  3. Ball  •  Oct 17, 2011 @7:30 am

    Matt, that’s the problem I have with Euler as an exercise in TDD I’ve done it both ways, and the last time I started, I just did some printing to screen because I don’t care about a suite of tests. It’s too slow, the problems are isolated, and there is usually only one sensible intermediate step that doesn’t take a lot of manual computation to set up.

  4. Tim  •  Oct 17, 2011 @8:45 am

    The nice thing about the Euler problems is that, once you get past the easier problems, they force you to think not only about how to get to the answer, but about the most efficient way to get the answer. The push towards thinking of the non-obvious is, in my opinion, easily the most important take-away from Euler.

  5. Ball  •  Oct 17, 2011 @12:27 pm

    Totally, Tim. That’s why I do like them. It puts Big-O right in your face in a way normal (of the kind I do) dev doesn’t seem to do.

Leave a Reply

Allowed tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>