ICFP Programming Contest 2008
I spent the last 72 hours programming in the ICFP Programming Contest 2008. I actually took vacation days on Friday and Monday so I could fully participate. It was a lot of fun and I’ll definitely do it again next year. The organizers did a great job.
Here are the really good things about this year’s contest:
- The problem was nice. It wasn’t one of those either-you-see-the-solution-or-you-don’t-see-it problems. Yet, it kept you engaged for the full 3 days and there was still a lot of stuff I would have liked to have tried but didn’t have time for.
- They offered support for Mac OS X. Thank you, thank you, thank you.
Now, here are the bad things about this year’s contest:
- Common Lisp was not a fully-supported language. Yes, that’s right, in a functional programming contest, Common Lisp was not a fully-supported language. I know, I know. You were allowed to submit a static binary written in any programming language you wish, and this was supposedly not a ‘barrier’ to using other languages. Well, I’m sorry, but it is a barrier if you’ve never before in your life prepared a static executable from Common Lisp for Linux and rarely even use Linux. I hate to rail on the organizers about this, but I really do think in a contest designed to promote functional programming, you should have Common Lisp (and Scheme and Haskell (which they did have)) as officially supported languages. Couldn’t they have left out, say, I don’t know, Java? I was really looking forward to using the contest to increase my Common Lisp skills a bit. However, I knew that my Linux/command line ineptitude would mean I’d spend 71 of the 72 hours trying to create the executable. So, I went with Python.
- They didn’t come out with the Mac OS X sample server at the start of the contest. It came out (if I remember correctly) very late on the first day of the contest.
So, those are my 2 criticisms. The first, I think, should not have happened. As far as the second goes, I realize the contest organizers are not running this for my benefit, so I am grateful that they did give testing support for Mac OS X, even if it was a little late.
Here are the things I learned and plan on doing differently next year:
- Have a Linux box ready next time and get used to it well before the contest. Learn how to make a static binary from Common Lisp ahead of time. (But, please, just add Common Lisp back to the list of official languages next year and drop Java or whatever.)
- Have a team. Maybe if you’re Richard Stallman, you could win the contest by yourself, but I’m not Richard Stallman. I think a team of four (like the Beatles!) would be perfect. There were a lot of things I just didn’t have time to try. Wild ideas that might or might not have panned out. With 4 people, if one person wanted to try out a wild idea he had and it failed, it wouldn’t have been the end of the world. Also, with 4 people, you could have one person writing test cases and testing. Also, with 4 people, you could motivate each other to keep going. 4 people all working in one house together would have been ideal.
- Use source code control. Even with just one person writing code, this would have been nice. What I basically did was save off ‘committed’ versions of files in zip files with time stamps. This basically amounted to source code control but it was error-prone and not as simple as just right-clicking on a file in Eclipse and saying “check in”.
- Most importantly: In the next year, continue learning all the important Paul McCartney bass lines from Revolver to Abbey Road (inclusive) and finish reading and doing the exercises in Structure and Interpretation of Computer Programs.
So, thanks to the organizers for running this. Now I just have to try to get out of this [t|w]ired, dead-on-my-feet state and rest up 2 days for the Google Code Jam (and (of course) go to work in the meantime).