ICFP Contest Underway 43
iseff writes "The ICFP Contest (reported first here) is now underway. There's probably still some time for us slackers to code up something for the first round. This year's problem is similar to the board game Cops and Robbers. What I find cool about this year is the split into two parts -- code the original spec, then wait, get a new spec, and modify. Plus, any language is accepted, even though it's a 'functional programming' contest."
More on the task (Score:5, Informative)
What is really interesting though, is the format in which the tournament is going to be played. Every game will consist of 5 cop bots going against 1 robber bot. The cop bots will be written by individual participants - and will have the capability to communicate with each other, suggesting 'plans', and voting on them to elect the best one. The whole team gets rewarded if the robber is caught, but you also get individual bonuses for individual achievements. This adds a byzantine-generals like dimension to the problem, since the strategy is always a mix between cooperative effort and individual greed.
The last and most important twist is the fact that the second round is worth 'significantly' more than the first, and involves adapting your bots to a modified version of the problem. What this modified version will be is a closely guarded secret... but it means that it's probably a good idea to spend as much time thinking about the design as thinking about the strategy.
Re:knee deep in garbage (Score:1, Informative)
This is a straw man. Nobody claims this apart from the zealots, and they can be ignored like all other fanatics.
What serious FP users claim is that FP can solve many classes of real-world problem with greater ease than existing imperative languages.
There is some truth to this claim. Many OO design patterns have far simpler equivalents in FP languages. The visitor pattern, for example, is nothing more than an extremely complicated, tedious, and inefficient substitute for pattern matching on algebraic datatypes. FP languages are highly optimised for tree processing, making them ideal for any application that uses XML.
There are also problems which FP does not make any easier; for example, simple text processing applications are typically much more complicated to write in FP languages than in specialised scripting languages like Perl or Ruby, while event-driven GUIs are a problem ideally suited to an OO approach, which is another weak point of FP languages (though there are FP/OO hybrids like OCaml and Lisp's CLOS which go some way to dealing with this problem).
If you're interested in seeing what FP has to offer imperative/OO developers, just look at the Boost libraries for C++. Many of the ideas there, like closures and lazy lists, have been drawn from FP research. Sounds like someone thinks FP is interesting enough to be worth serious effort bending a non-FP language to support it.
The garbage collector is a solution to that problem. In the presence of dynamic scoping, it is the only general solution that has been discovered so far. The only method of memory management that provides superior speed and efficiency is static allocation on the stack, and that is a great restriction that makes programming considerably more difficult.
What exactly is your problem with GC? It removes a major source of bugs and decreases the complexity of a program considerably, without introducing any major disadvantages. So why are you so hostile to it?
Re:knee deep in garbage (Score:1, Informative)
Re:knee deep in garbage (Score:2, Informative)
LISP really can't be categorized as a post-C language, as it was created roughly 15 years before C.