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

[Haeleth]

Funnily enough, I came away with the impression that C++ had an advantage this year, since the removal of the requirement that the judges run the program themselves meant, in theory, that a brute-force approach combined with a supercomputer could have beaten the most delicately honed algorithm imaginable. That the winner was not an example of this surprised me.

Ah well. Those of us with functional inclinations can console ourselves with the knowledge that at least the winning program didn't use COBOL...

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:What does ICFP stand for?

[LoneIguana]

from: http://developers.slashdot.org/comments.pl?sid=688 44&cid=6294481 [qoute] ICFP stands for International Conference on Functional Programming. Neither the /. story nor the contest website make this clear [/quote]

Access to fast machines required?

[Ben Escoto]

This contest concerned virtual racing tracks. The winner was the one who submitted the trace which would pilot the car as fast as possible around the track. (See the problem description for more information.)

Thus the judges never ran the program on their computers, and in theory could have judged the contest without even looking at source code. To me this seems a bit unfair because the winner could just be the one with the fastest computer, not the best code. I noticed that the first prize team used 16 dual Xeons.

So did anyone here compete? In practice are the results greatly influenced by how much hardware the contestants had access to?

2002 ICFP language breakdown

[truth_revealed]

Values taken from the ICFP 2002 webpage and munged with an awk script... not 100% accurate, but close enough.

language entries

java 28
c 24
c++ 22
caml 19
python 15
perl 11
scheme 7
haskell 6
lisp 5
dylan 2
erlang 2
mercury 2
pltbot 2
ruby 2
ada 1
bot! 1
dogs 1
extensions 1
forth 1
icon 1
kylix 1
lspm 1
mhotas 1
pandemonium 1
pps 1
prolog 1
sk 1
smalltalk 1
sml 1
v202 1

Some languages are bogus because of the format of the author's entry, or they used multiple languages.

Re:'red' TopCoders

[lars]

TopCoder is a company that recruits programmers, sells software components, runs high school contests, etc. (They probably do other things now too.) One of the main ideas behind the company is to rate programmers as objectively as they can. This acknowledges the fact that experience or specific skills on a resume don't necessarily provide a good indication of the programmer's true ability and productivity. The main way TC evaluates coders is based on programming competitions and component design and development competitions.

I've been participating in TC's programming contests for more than a year. There are weekly contests, each of which take only about 90 minutes of your time. There are no prizes given out for the regular contests any more, but I really enjoy being able to get a nice mental workout, and compare myself to some really elite programmers. Most of the top-ranked coders have done extremely well in other prestigious international math and programming contests. And even if you aren't at the level of the top ranked guys (mostly - I think the highest ranked woman is around 50th or so, it would be nice to see more female participation), it can still be fun to work on improving your rating and other statistics such as submission accuracy. The rating system is modelled after the FIDE system for rating chess players.

There are many other reasons to participate. You can also learn a lot by looking at the submissions by the top ranked coders. If you're looking for a job and do reasonably well, there's a good chance one of the many sponsor companies will be interested in hiring you. And perhaps most of all, TC has two big tournaments each year - the open, and the college invitational. These tournaments usually have a total prize purse of $100,000 or more, and pay out $50,000 or more to the winner.

Finally, to answer your question; the TC ratings brackets are split up into different colours. 'Red' is the highest bracket, and includes anyone with a rating higher than 2199. This corresponds to roughly the top 2% of all rated members.

Re:Of course

[angel'o'sphere]

Your comparision is not quite correct.
FP is all about making algorithms primary and data secondary.
In FP, functions *ARE* data. The main way to distinguish programming languages, or programming paradigms, is by looking at the question: what are the so called "first class citicens?" (fcc)

In "procedureal" languages the fcc's are *NOT* "procedures", its only called procedural because the main "structuring" feature at that time was the procedure.
Functional languages are best set in relation to oo languages (or oo-like languages like Java and hybrids like C++). The most heavyly used fcc's in oo languages are objects. Thats what you create and what you pass around. E.G.: you create an object and pass it via a call to an algorithm.
In functional languages, the things you create are: functions, not objects, not structs. the things you pass around are functions, you *apply* a funcion on some data.
In both cases you still have data, and still you have algorithms.
What makes fuctional languages "inefficient" in some respects is the fact that they in general do not manipulate "state" of some data, but consider data to be read-only and yield an result instead. Suppose the whole kernal memory is the state of a system, a functional "kernal" would compute a complete new kernal state as a value object.
OTOH: functional languages are inherently multi threaded, as they only read access unchangeable data.
Regarding your - hypotetical - question wether a scheme parser written in scheme would be easyer than a standard C/Pascal parser ... who knows? Scheme is that easy to parse, that the questin makes no real sense to me. It only looks more beautyfull if you find scheme beautyfull ... wich I don't :-)
BTW: its is often very difficult to express algorithms in a pure-functional manner that have the same asymptotic complexity as their imperitive counterparts
This makes no sense to me, either. The asymptotic complexity of a problem has no relation to the programming paradigm you use -- only to your skills in that paradigm.
angel'o'sphere

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