Our team's progress so far in the ICFP Programming Contest has been rather discouraging. OCaml's limit on the length of strings is a problem for us. Andrew's computer's hard drive has apparently died, which doesn't help matters. It's a good thing that uninja has Wii tennis and lots of tea.

Greetings from Chez uninja, where pwinkler, LJ-less Andrew, and yours truly have joined our host for a long weekend of geekery as we tackle this year's ICFP Programming Contest. Here (pdf) is the task description. uninja and pwinkler are taking on the DNA-to-RNA translation, while Andrew and I are working on the translation from RNA to alien creature. :) We've been using Python to start out with, but we've been bumping up against the language's slowness and its limited recursion depth. So now we're trying to learn Objective Caml and re-code our work so far—except for pwinkler, who refuses, and is using C instead. We've done pretty well at maintaining a cross-platform network/repository/codebase, as we stubbornly stick to our own hardware, operating systems, and development environments.

Thanks to teammates Andrew and uninja, who just finished the video editing, here's an action-packed look at our programming contest team at work back in July:

This year's programming contest is winding up in the next couple of hours. Whereas last year I tended to feel sleepy early and get up early, this year my problem has been getting up when I plan to.

It's turning out that my best-first-search approach to the plinko puzzle is still grindingly slow in practice. It's frustrating to have put so much effort into a program that so far hasn't yielded any more points for our team. I have to admit that this year's challenges are especially well-suited to functional programming techniques, a feature that past ICFP programming contests haven't necessarily included, leading us to throw Python code around without thinking functionally. On another note, I like how exploratory this year's challenge is; that makes it fun. It's a little like an alternate reality game in that sense.

As there was last year, there will be a time-lapse video of our team at work. When it becomes available—the teammate with the video camera is recovering not only from the programming contest but also from last week's conference and from a head cold—I suspect you'll notice we spend much less time talking with each other than we did last year. The discreteness of this year's puzzles made them easy to parcel out to different team members, but that also made us more isolated from each other in our efforts.

We're beginning another day of competition in the programming contest. Out of 281 teams on the scoreboard (you have to implement the virtual machine correctly before you even have a chance to get on the scoreboard), we're currently in 66th place. For those of you watching at home, we're 'the code alchemists'. We all like this year's scoring system where solving various puzzles gets you incremental points that are then reflected almost real-time on the scoreboard, rather than last year's system where you had no idea how you or other teams were faring, relatively speaking, until the results came out months after the contest.

I'm going to continue working on a plinko (like パチンコ) game where you have to come up with plinko boards that make the marbles come out in certain ways. Brute force generation of all possible plinko boards followed by matching their outcomes with the one you want works only for very small boards. My challenge is to do this for large boards, creating some intelligence that looks for 'better' boards first. I'm creating a grid one row at a time from the top down, choosing some row permutation each time that appears to get the marbles closer to their goal state. If I were smarter, maybe I could come up with a way to work up from the bottom of the grid instead of down from the top.

So, we've got the virtual machine working along efficiently in C. The program that was supplied by the contest organizers to run with this virtual machine turns out to be a sort of Unix-like environment (called UMIX) with a variety of puzzles/challenges. Andrew is dealing with a graphical (well, for graphics on the order of ASCII art) functional programming language thing. uninja is working on an XML-like substitution-language thing. Me, I'm playing a text adventure game included in the program. ;) I love programming contests.

(Our teammate Mike could only stay for a few hours yesterday because he's moving into a new house that needs a whole lot of work done.)

I'm back home now, immersed with three teammates in the ICFP 2006 programming contest. We're writing a virtual machine in Python, but it's turning out to be hideously slow, so we're looking into profiling and optimizing as well as rewriting parts in C.

The dates for this year's ICFP Programming Contest have been announced: July 21-24. That's significantly later in the summer than I would have expected, and it could be problematic in that I and probably one of last year's teammates will be at the SMC-IT Conference in Pasadena from July 17 to 21. Hmmm.

Excitingly, at the Pasadena conference I may get to present a paper, "The Evolution of a Test Process for Spacecraft Software," which I didn't even write. (My colleagues who authored it—and got it accepted—won't be able to go to the conference.) That would dramatically increase the chances of my employer paying for my attendance at the conference as well as make me feel more important there. The conference schedule appears to be undecided, so I have no idea which day I'd be speaking.

I had a lot of fun doing last year's programming contest, though, so maybe there's a way I can work it out for this year.

After months of waiting, we have the results of this year's ICFP Programming Contest. As expected, we didn't win, we didn't do abysmally, either. I think.

One of the winning teams used a language I'd never heard of before called Dylan, and the others used Haskell. I wonder to what degree a team's choice of programming language influenced their performance; the Dylan users think their language gave them an edge. I wonder how the winning teams would have done if they'd used different languages. Maybe they're so hackerly that their analytical skills are the deciding factor.

The contestant programs were time-constrained, but we didn't have much of a problem keeping within the time limits, using Python. It's not clear to me that that using a compiled or time-optimized language would have made much difference.

Our cop and robber seem simply not to have been clever enough. What remains is for us to figure out what sort of cleverness they lacked.

A while back, someone who saw our ICFP Programming Contest team's video suggested the idea of getting team shirts. And it has taken me until now to mention that I'd set up a Cafepress store with Python-themed memorabilia. It's not really team-specific merchandise, which would have to depict a springy seahorse, but it's at least related, inasmuch as our team used Python.