We at Starling are starting to gather up all of our friends and gear up for the 2009 ICFP Programming Contest. There’s interest from about a dozen people this year, so it looks as if we’ll have quite the three day party!
With this many people, even though we’re (almost) all functional programmers, we don’t share a common preferred language and platform. This, of course, has provoked discussion. I thought I’d put forward here some of the criteria you should consider when thinking about what languages to use as you approach the contest.
But first I ought to answer the question, why think about this in advance at all? I think it’s fairly evident that the best language for your team to work on any particular contest problem can’t really be known until you see the problem itself. And there may in fact be several best languages for different parts of the problem. (It’s not unusual to have to write several different programs during the course of the contest, even if the final submission is a single program.)
The point is, however, not to finalize your choice in advance, but to be prepared to make that choice quickly when the moment comes. This preparation has two parts. The first is to be aware of your strengths and weaknesses with regard to various languages, platforms and tools. The second is to prepare the platforms themselves so that they’re at hand for use when you need them. It can really hurt you in the contest if you end up spending hours getting everybody set up with a compiler and the appropriate libraries, and more hours ensuring that you can submit a runnable program to the contest organizers when they’re running it on a machine without all of your stuff installed.
So now let’s have a look at the criteria.
While there may be a few people out there who enter for some sort of serious purpose, I expect that, for most competitors, fun is the main reason for competing. Thus, pick languages and platforms that you’ll enjoy using. This criterion overrides everything else: even if you didn’t manage to generate a submission, if the experience was enjoyable and you learned something, those are worthwhile achievements in and of themselves.
It’s perfectly reasonable to use the contest as an opportunity to learn a language you’ve never used before. That said, you’ll still probably find things much more enjoyable if you spend a bit of time preparing in advance, both playing with the language a little and getting your platform and build system set up before the contest starts.
While a good programmer can usually learn a well-designed language or library quickly, there’s a huge gap between understanding something and having used it extensively. Parts of this gap, such as understanding and learning to apply new concepts, can be attacked more quickly merely by applying more brain power, if available. But other parts, such as all of the inevitable quirks a platform has when used in the “real world,” appear to me to be conquered only by experience. Knowing in a fair amount of detail how various types of garbage collectors work will certainly give you some insight into how a particular platform’s garbage collector works, but someone with slightly less general knowledge but hundreds of hours of experience dealing with a particular platform’s GC will trump that every time.
Be prepared to use what you know well, lest you get near the end and discover that you’re spending hours debugging something that you could have fixed quickly if you were working with something more familiar.
It’s not necessary that all the team members, or even most of them, have this knowledge, just that the knowledge and experience is available from someone within the team.
The organizers of the the first ICFP Programming contest wrote ”…performance matters.”. And it does. Ideally you want to have available a comfortable, familiar platform based on a reasonably efficient compiler. You may not need it, the 2008 contest being an example in point. But contestants have from time to time found themselves getting into trouble because they couldn’t complete a program run within the time limits imposed by the organizers, or merely process raw data fast enough.
If you’re lucky, the ability to interface your platform of choice with a low-level language such as C can be helpful here. But dropping down to C often takes more programming time than working in a higher-level language, for little benefit over a good compiled higher-level language platform.
Those organizers also wrote, “Algorithm cleverness matters.” And it does. But there will be cases where that can’t help you enough, if your platform is too slow.
The organizers of the first contest in 1998 said, “We have specifically chosen a parallel machine for the contest so that programs may exploit parallelism.” I’ve not seen any mention of this since, but lately multi-core CPUs and prognostications about how you’ll have to be parallel to survive have been increasing in popularity. Whether it’s true or not that you will, I wouldn’t put it past contest organizers to set up a problem where being able to parallelize your code for an SMP system would be a significant advantage. Think seriously about making sure you’ve got a platform available that will allow you to use SMP parallelism without too much difficulty or inefficiency.
While sometimes you’re given data to process and need only return the result of that processing, as often as not, the contest organizers require that you submit code that they can run on their systems. Generally they’ll try to provide a reasonable selection of popular compilers, interpreters, libraries, and so on, but they can’t have everything. Last year was a notable case: the programs were run under a Live CD environment that had quite limited space available, and some languages had unexpectedly minimal libraries available. For example, though the contest required the program to do network I/O, the GHC networking libraries were not available on the CD, and we had to statically link them in to our binary.
Be prepared for this. Ideally your platform will let you submit a binary with anything beyond the basic stuff (such as libc) statically linked in to it. If you’re using an interpreter, be prepared to include in your submission any non-standard libraries, and any newer versions of standard libraries that have bug fixes or features on which you depend.
In advance of the contest, set up your build system for each platform you’re considering on all of the machines you’ll be using. The last thing you want to be doing is struggling with problems installing or running a tool while the contest clock is ticking away.