Egér a Marson - ICFP contest 2009 (v0.10). See also last year.

Some statistics to boot:

• 3 people
• 3 programming languages (Haskell, Python, Delphi)
• 3 operating systems (OSX, Linux, Windows)
• Large amounts of coffee and beer, not much energy drinks (unlike last year)
• Large amounts of cigarettes (for the others)
• Not much sleeping
• 6 computers (5 colocated) in various roles and uses (for example one was used to play music)
• We scored around 2200 "weighted" points (I don't recall the exact value, and the team page is shut down now); solved the first two tasks, solved the third one except the scenario with the almost parabolic orbit, and started to solve the final task (but the code was slooooow and we ran out of time). All of this was accomplished by the Haskell code.

Some conclusions:

• VMs should be written in C. Speed matters, and you shouldn't spend your precious time by waiting for the buggy solutions to run again and again. It's not the first time we ran into this issue. In retrospect, not spending 20 minutes to code a VM in C was probably the biggest mistake I made this year...
• Teammates should really use the same tools, eg. the same language, the same OS; but this is pretty much impossible...
• Better resource management: We shouldn't all work on the same problem and produce 3 buggy implementations of the same thing
• Know your libraries, so you don't have to hack half-assed vector non-libraries during the task (well, this is a lecture for the other two guys, I was pretty happy with my own vector library)
• Coffee is better than energy drinks :)
• Haskell is stil great!

About the task:

While at first sight this year's task looked like a mixture of last year's task and some previous year's tasks, I ended up really liking it. I don't usually work with (non-integral) numeric data, so while I'm aware of the existence of numerous issues and land mines, it still surprised me when for example we had to correct an error which was smaller than timestep of the simulation. I also have a newfound respect for NASA and all the space pioneers :) Another subtle thing was how to organize the mission strategies. To me, this begs for some FRP-like approach, and I ended cooking up something with the remote flavour of that (the thing is, I have only a very fuzzy intuition about what exactly FRP is). The VM thing solved the the architecture-dependency of last year, though it lost the warm realtime aspect in the process.

The story in short:

Later.