Getting ready for ICFP 2008

The rules for this year's ICFP contest have just been posted. Although the actual problem won't be posted until Friday July 11th, the rules themselves are interesting:
  • Your code will be run on a 1GB RAM 4GB swap 2GHz single-processor 32-bit AMD x86 Linux environment with no access to the Internet.
  • You have to submit source code.
  • You may optionally submit an executable as well (useful if for example you use a language that isn't one of the short list of languages provided by the contest organizers.)
  • Teams are limited to 5 members or less.
I have mixed feelings about these rules. The good news is:
  • It should be possible for most interested parties to recreate the contest environment by using the contest-provided Live CD. A computer capable of running the contest could be purchased new for around $350.
  • It seems that the focus will be on writing code in the language of the contestant's choice, rather than writing code in the language of the contest organizer's choice. This wasn't the case in some previous year's contests.
  • It provides a level playing field in terms of CPU resources available to contestants.
  • It ensures that the winning entry is documented. (A few years ago the contest winner never wrote up their entry, which was quite disappointing.)
The bad news is:
  • It penalizes contestants with low Internet bandwidth. The Live CD image is not yet available for download, and I anticipate some contestants will have difficulty downloading it in time to compete in the contest.
  • It penalizes non-Linux users, who are forced to use an alien development environment and operating system.
  • It penalizes languages too obscure to make the contest organizer's list. That goes against the whole "prove your language is the best" premise of the contest.
  • The target system is 32 bits and single core, which is at least five years out of date, and does little to advance the state of the art. This penalizes many languages and runtimes. For example OCaml has a harsh implementation limit on array size in 32 bit runtimes that is relaxed in 64-bit runtimes.
  • It seems as if there won't be any during-the-contest scoring system, so we will have to wait until the ICFP conference to find out how the contestants did.
Still, I'm hopeful that the contest itself will still be enjoyable. I look forward to reading the actual programming problem on Friday.

Comments

Post a Comment

Popular posts from this blog

GLES Quake - a port of Quake to the Android platform

I've just published the source code to a port of Quake to the Android platform . This is something I did a while ago as a internal test application. It's not very useful as a game, because there hasn't been any attempt to optimize the controls for the mobile phone. It's also awkward to install because the end user has to supply the Quake data files on their own. Still, I thought people might enjoy seeing a full-sized example of how to write a native code video game for the Android platform. So there it is, in all its retro glory. (Porting Quake II or Quake III is left as an exercise for the reader. :-) What's different about this particular port of Quake? Converted the original application into a DLL Android applications are written in Java, but they are allowed to call native languge DLLs, and the native language DLLs are allowed to call a limited selection of OS APIs, which include OpenGL ES and Linux File I/O. I was able to make the game work by using Java for: T
Read more

A Taipei-Torrent postmortem: Writing a BitTorrent client in Go

This is a BitTorrent client. There are many like it, but this one is mine. -- the BitTorrent Implementer's Creed For fun I've started writing a command-line BitTorrent client in Google's go programming language. The program, Taipei-Torrent , is about 70% done. It can successfully download a torrent, but there are still lots of edge cases to implement. Go routines and channels are a good base for writing multithreaded network code. My design uses goroutines as follows: a single main goroutine contains most of the BitTorrent client logic. each BitTorrent peer is serviced by two goroutines: one to read data from the peer, the other to write data to the peer. a goroutine is used to communicate with the tracker some "time.Tick" goroutines are used to wake the main goroutine up periodically to perform housekeeping duties. All the complicated data structures are owned by the main goroutine. The other goroutines just perform potentially blocking network I/O using channel
Read more

Writing an Android application in JavaScript and HTML5

Image
Happy Mother's Day everyone! This year I wrote an Android app for my wife for Mother's Day. How geeky is that? The reason I wrote it is that my wife's favorite Android application, Word Mix Lite, recently added annoying banner ads. While the sensible thing to do might have been to switch to another app, or perhaps upgrade to the paid version of Word Mix, I thought it might be interesting to see if I could write my own replacement. And as long as I was writing the app, I though I'd try writing it using JavaScript. Normally Android applications are written in Java, but it's also possible to write them in JavaScript, by using a shell application such as PhoneGap . Why use JavaScript instead of Java? Well, hack value mostly. On the plus side it's a fun to write! Another potential plus is that it is theoretically possible to run the same PhoneGap application on both Android and Apple. The drawback is that PhoneGap is not very popular yet, especially among Android dev
Read more