Slashdot Mirror
ICFP 2003 Programming Contest Results
An anonymous reader writes "The previously reported ICFP Contest has been over for quite some time. The results were announced on August 26, 2003 at the conference in Uppsala, Sweden, yet the contest organizers have yet to publish results. Despite the forgetfulness of the organizers, it is known that this year C++ did well, taking first and second, but not judge's prize. Interestingly, a one-man team consisting of an undergraduate student took first place, followed by a team of highly ranked 'red' TopCoders, with the maintainers of Gwydion Dylan taking judge's prize."
I wonder how many job offers 1st place winner and UT undergrad Andrew Hudson is going to receive... or for you conspiracy folks out there, how many shadowy organizations he'll be "invited" to join.
Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
Its nice to see my two favorite languages take the top spots :) Its also pretty nifty that the Gwydion Dylan team got another prize. They got second place a couple of years ago too. Anyway, more people need to check out Dylan. Its a pretty nifty language. It was made by Apple in the early 1990's, by a committe containing a lot of important Lisp people. As a result, its kind of an object-oriented Lisp with a more traditional syntax. Its a very powerful language, but also very fast. It was designed to achieve 90% the performance of C. In practice, the current Gwydion compiler (designed by the same group at CMU that did CMUCL) achieves 50-90% given similar code.
A deep unwavering belief is a sure sign you're missing something...
Congratulations! I've usually steered clear of checking out programming "challenges" because they usually seem to be focused on producing the most unreadable or obscure code to confuse the judges.
While you can learn things from obfuscated code, I think these practical challenges are a lot better for the programming community as a whole.
Finding optimal paths around race tracks and obstacles presents a number of challenges which when solved in multiple totally different ways, helps give us new theories and data which we can use to develop new algorithms and theories for use in the real world.
Can anyone recommend any other programming challenges which focus on developing new algorithms which may be useful in other disciplines?
The only example I can think of is the many "robot" fighting challenges, where you write a program for a robot, and it has to destroy the other robots within the battlefield using its own "wits" and no human input. You might remember PC-ROBOTS from the early 90's if you're a real geek ^v^
Web Hosting Reviews
I guess it should come as no surprise that the winners should be programming in the decidedly non-functional (no pun intended, really) language C++. There are far more C++ programmers out there than Dylan, Haskell, and ML combined, probably by a couple orders of magnitude.
The prizes were awarded based on answer quality, not performance, which takes away one of C++'s natural advantages over functional languages. Still, I'd like to see a breakdown of entry languages.
It's interesting to note that even though there were a lot of Java entries - more than any other language - they did not rank very highly. The sheer number of programmers for a given language does not necessarily lead to better solutions in that language.
Somethign nobody has mentioned yet (at least with a high rating) is that this is the contest for the International Conference on Functional Programming, and not only that, from the rules page:
First prize: $1000, free conference registration for two student team members, and the satisfaction of hearing the judges proclaim your programming language "the programming tool of choice for discriminating hackers."
Second place language gets: "the consolation of hearing us proclaim your programming language "a fine programming tool for many applications." "
So, I want to make sure this is clear: At the International Conference on Functional Programming, the judges had to get up a proclaim that "C++ is the programming tool of choice for discriminating hackers."
I would've loved to be there. Anybody who was at ICFP care to comment?
I entered using a fairly average machine (Apple powerbook G4). It looks like I came in 30th out of about 90 entries (I'm "apple2gs"). I'm disappointed that I had to find out results through slashdot.
My strategy was to try to use "waypoints" to help guide an optimizing algorithm, but I gave up and just made a manual car simulator (meaning, you manually enter the commands, and my program just shows where the car is and if it's hit a wall yet). With more time, I could easily improve most tracks by at least 5% by just racing them through again. This would only move my rank by a few places, though.
So machine speed was not that big a factor in my case. Others also made simple driving simulators as well, although I don't know how well they did overall.
The winner noted:
(here)He also probably wrote the least amount of code of anyone. (A link to his source is posted in the same forum.)
To be fair, he also took an approach that my team wrote off as unachievable when it obviously wasn't unachievable--brute force search of the solution space. (Specfically, brute force search of the "whole" solution space reduced by restricting solutons to only change control settings on pixel crossings [and certain quantized speed changes].)
Meanwhile my team's solver got beat by some people who just interactively solved the courses with a human driver. Embarassing.
Read this message from a recent thread about the subject on news group comp.lang.functional.
I was aiming for manual assisted computer driving. Something like providing the control points and let the computer draw the Bezier spline.
To brute force the general problem I wouldn't dare in the first place.
I wasted most of the time reading and writing stuff between the various formats and to get my simulator implementation running exactly like the official one. Which was probably 1-2 days too much. Coming up with such an optimizing GUI would have taken another 2-3 days for me.So the winners did a good job.
Regards,
Marc
I was on the team that won the judge's prize, and whilst you can read our report at the link above, I have to say that for us, the key was the human, not the hardware or the program.
;)
The tracks we did well one were the ones that we were able to hand-drive accurately; the ones we did badly on were the ones where there were simply too many hard turns to make that feasible.
Despite having a whole university lab full of computers we could have hijacked to run our program on, we only used a single computer for the actual optimizing.
Also note that although our automatic optimizer was written in Dylan, the visualizer/racing game program was C++.
If I were going to be controversial I would say that it all just goes to show that humans are better than computers and imperative languages are better than functional ones