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."

Comments

Godspeed, Andrew Hudson

[stevesliva]

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.

Awesome

[be-fan]

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.

Useful programming challenges

[JusTyler]

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^

Non-functional programming languages

[jfengel]

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.

Re:Non-functional programming languages

[Ben Escoto]

It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).

In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list. In fact the entry list is interesting in itself to see all the languages people use.

And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.

Re:Inrternational Conference On Functional Program

[mvw]

I would've loved to be there. Anybody who was at ICFP care to comment?

Read this message from a recent thread about the subject on news group comp.lang.functional.

Perspective from Judge's Prize team

[onesadcookie]

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 ;)