Slashdot Mirror

← Back to Stories (view on slashdot.org)

ICFP 2004 Programming Contest Results

Posted by timothy on from the smaller-bikinis dept.

jnagra writes "The results of the 2004 ICFP Programming Contest have been announced. First place is to a program in Haskell, second place is to a program in C++, and the judges' prize is to a program in OCaml. The ICFP contest is an annual contest to promote functional languages (although programs in any language are accepted) and bestows on the winners unlimited bragging rights."

30 comments

  1. Lighting division by straybullets · · Score: 1

    From tfa :

    Full Lightning Division Results
    Place Points Team Team size Ant Approach Language Ant size
    1 32868 RedTeam 7 L2 higher Perl 1263
    2 32811 RedTeam 7 L1 higher Perl 1079

    Perl scores again :)

    --
    With that aggravating beauty, Lulu Walls.
    1. Re:Lighting division by GigsVT · · Score: 2, Informative

      The contest really had little to do with the languages involved, since the judges never even ran the contestant's code!

      The judges just ran the output from the contestant's code through a simulator.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
  2. Ants by shfted! · · Score: 1

    I don't know about you, but I, for one, was antsy to see the results!

    --
    He who laughs last is stuck in a time dilation bubble.
  3. Visualizing the winners by TheRealFoxFire · · Score: 4, Interesting

    For those of you who want to see the winners in action, the Formicidae simulator from Ant Wars can be used. It comes with a converter from the ICFP language to Ant Wars bytecode. To do so:

    1. Grab a copy of Formicidae from the download page
    2. Use the included convert.py on an ICFP .ant file:
    convert.py <filename.ant>
    3. Run formicidae.[sh|bat], and provide a world (ICFP maps included in the worlds/ subdirectory) and two .antc files
    4. Check ICFP Mode
    5. Enjoy the match

    Interestingly, this year's winning ant is already beaten by some of the competitors on Ant Wars, due to the fact that some Ant Wars ants have more aggressive defensive tactics that wind up decimating Dunkosmiloolump's ants that too brazenly approach their ant hill.

    1. Re:Visualizing the winners by hsenag · · Score: 1

      Did you try our second ant? That one is just like the other except that it explicitly avoids the enemy anthill. Of course, if you set a trap just outside or something it's just as likely to fall in as the other one.

      The main tactic that is really effective against our ants is encircling our anthill. Luckily we often manage to collect more than half the food before an enemy has managed to do this. If I had time to improve our ant one of the main things I'd do is task some ants to act as a "tunnel"; this would stymie most encircling tactics.

      -- The "lump" in Dunkosmiloolump

  4. "Already?" by Lucas+Membrane · · Score: 2, Insightful

    These guys built their ant-building and testing system and made their great ants in 3 days! And they didn't see the competition to figure out how to beat it. Three months later some non-winners finally come up with something that can stop them, and that's "already"?

    1. Re:"Already?" by TheRealFoxFire · · Score: 2, Interesting

      My point was rather that some Ant Wars ants, which have been created in the last week, not three months, defeat the winner which they had never seen.

      I'm not trying to take away from the winning teams accomplishment, which is stupendous, but rather to point out that its interesting that there were no ants in competition which aggressively defended their bases.

  5. What happened to Dylan? by Lucas+Membrane · · Score: 1

    Dylan language had some strong entries in previous years, and now it's presently absent 100% from the results. What gives there?

    1. Re:What happened to Dylan? by Anonymous Coward · · Score: 0

      The Dylan guy got lost on the way to the competition.

    2. Re:What happened to Dylan? by brucehoult · · Score: 4, Interesting

      We (DylAntz) were there, we just seem to have had an "off" year, managing only 25th out of 87 in the lightning (24 hour) contest and 137th out of 361 in the main (72 hour) contest.

      It would be nice to win every year, but actually I'm pretty happy with a record that goes:

      2001: 2nd
      2002: 35th
      2003: Judge's Prize
      2004: 137th

      I think this year's contest results had very little to do with how good your chosen programming language is. Instead it was all about how well you could get around the limitations of the ant instruction set and devise strategies for your ants to follow.

      Sure, you could make a compiler that gave you a language with loops and subroutines and (very limited) variables and turned that into ant code -- and we did that -- but in the end you had to have something smart you wanted to get your ants to do. We spent a lot of time on making out ants explore the world and gather food efficiently (including raiding the opponent's nest), but our strategy for defening our own nest turned out to be inadequate.

      For some reason the results say we used Perl, not Dylan. I don't know why. It's true that we had a quick&dirty ant assembler written in Perl that some of us used to play around with strategies while we waited for the proper compiler (written in Dylan) to be ready, but that wasn't used for the final submission.

      We submitted the following programs all written in Dylan:

      - world simulator library
      - very fast simulator (2 sec for 100,000 rounds)
      - slow simulator with OpenGL interface for visualization
      - high level compiler for ant brains

      Congratulations to the winners and we're looking forward to next year's contest!

  6. The prize by YetAnotherName · · Score: 1

    ,,,bestows on the winners unlimited bragging rights.

    That almost makes entering worthwhile ...

  7. Congrats by hsoft · · Score: 1

    This year ICFP was my first try in a programming contest ever. This ant thing was really cool, and creating an AI in only 72 hours was really tough. Unfortunately, I couldn't even create a functional AI in time (I think it is because I spent too much time building a cool ant AI visualiser :) ), so I didn't really participate to the contest, but I tried :)

    I guess that actually using s functional programming language do help. Anyway, the winners deserve their unlimited bragging rights.

    I`ll sure do better for the next year's ICFP...

    --
    perception is reality
  8. Proud by Bluelive · · Score: 1

    Im proud to have the best score Java ant ;) 32th place :(

  9. Lisp results not very impressive by GCP · · Score: 3, Interesting

    I'm not quite sure what to make of the underwhelming results of teams that use Lisp in these ICFP contests every year. Of course I can see that there are many ways in which the contest isn't a "fair" test of language against language. If one team has a dozen Inria guys whose full time job is OCaml development against another team with a single Lisp hobbyist, it isn't much of a fair fight.

    It appears that winning depends more on choosing a good strategy than a good language and then implementing that strategy quickly and accurately. Choosing a winning strategy should be just as easy for a Lisp team as for anyone else, and helping you "discover" a good strategy is supposedly a strong point of Lisp. And as for implementing quickly and accurately, Lisp is said to have all sorts of advantages in that regard.

    Even so, the number of teams that choose Lisp each year and the relatively poor showing of those teams implies to me that the amount of advantage Lisp provides is not as great as some (e.g., Paul Graham) would have us believe.

    These contest problems are the sort of non-mainstream challenges that Lisp is supposed to be particularly good at, so I would expect more teams to choose Lisp to help them explore the problem and discover a winning strategy. Instead, Lisp appears to have, at best, average popularity among these programming language fans. I understand the overweighting in Haskell and OCaml given the name of the contest, but Lisp is roughly as functional as OCaml, so its lack of popularity puzzles me.

    And of those who choose it, the results don't seem to imply that it gave them any advantage.

    Yes, there are all sorts of ways in which the contest isn't a level playing field, but I'm still a bit puzzled at why the purported advantages of Lisp aren't showing up. Maybe they're real, but they don't appear to be very significant.

    --
    "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    1. Re:Lisp results not very impressive by John+Meacham · · Score: 3, Insightful

      Lisp's advantages are in a large part due to the general advantages of functional programming. Modern functional languages such as Ocaml or Haskell, have all those advantages plus 30 years or so of advances in type theory under their belt.

      One of the main advantages lisp has over languages such as haskell and ocaml is in self-modifying code, since in lisp, programs are data and it has dynamic typing. This feature probably just has not been useful in recent tasks.

      The winning place entry, used haskell to implement a domain specific langugae via a monadic combinator library, something Haskell excels at, so they were definitly using the languages strengths.

      Programming Haskell is truly a transcendent experience.

      --
      http://notanumber.net/
    2. Re:Lisp results not very impressive by brucehoult · · Score: 3, Interesting

      Even so, the number of teams that choose Lisp each year and the relatively poor showing of those teams implies to me that the amount of advantage Lisp provides is not as great as some (e.g., Paul Graham) would have us believe.

      Yeah, that puzzles me as well.

      Dylan is in essence a version of Lisp that happens to be written in a C/Pascal-like syntax instead of S-expressions. My friends and I have been doing pretty well using it, winning ICFP prizes in two of the last four years (2nd place in 2001 and Judge's Prize in 2003).

      That's a single team's record.

      There were 12 teams using Common Lisp and 9 teams using Scheme this year. I don't think we're any smarter than the other Lisp teams. In fact 7 of those 21 beat us this year, which is pretty much the same as our overall position in the field. So if our Dylan team is picking up prizes from time to time I don't know why other Lisp dialects aren't. It's a mystery.

    3. Re:Lisp results not very impressive by GCP · · Score: 2, Interesting

      I (think I) understand the theory behind the stronger typing in OCaml & Haskell vs. Lisp. It helps the compiler catch more bugs automatically.

      It seems to me as though this would slow down the initial process of exploring the problem, as Paul Graham claims. Proponents claim that it makes up for that by making larger systems more reliable.

      But these contest entries don't ever become large systems, and the extra slowdown initially wouldn't have time to pay off in the long run if the long run is only 24hrs (or 72hrs).

      Likewise with Haskell's isolation of side effects into the monad ghetto. Again, the theory of this is that the inconvenience pays off over the long run in reliability, if I understand correctly.

      I can understand the value of such features when creating avionics, nuclear power plant controls, or automated securities trading, but these contests aren't about reliability. They're about quick & dirty, do only what you have to do to score a short-term win. If a team ends up with a bug that doesn't impede their victory, then they still win. If the bug does impede their victory, then they lose, but it's hardly a costly loss, so they have little to lose by being more aggressive.

      Since they have so little to lose, I'm surprised that the majority of winners aren't primarily highly-dynamic/questionable-safety languages like Perl and Lisp. And I'm surprised that C++ ever wins, except where speed matters (as was the case last year, I think.)

      For the circumstances of this contest at least, it seems to imply that if you are good at figuring out smart approaches to a problem, it doesn't matter what language you use as long as you are VERY quick and reliable in expressing your intentions in that language, meaning so much experience with the language and its dev tools that you can write your code as fast as you can type.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    4. Re:Lisp results not very impressive by GCP · · Score: 0, Flamebait

      Yes, I agree with your assessment of the implementations, even though the CMUCL and SBCL *compilers* have some impressive characteristics.

      Still, a contest like this doesn't require much from the platform. You don't need to put the system into production or keep it maintained. You just have to solve a programming problem in a one-off sort of way that takes away a lot of the advantages that the most popular platforms have in more mainstream, enterprise-type problems.

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
    5. Re:Lisp results not very impressive by hsenag · · Score: 1

      I have no experience with Lisp/Scheme etc, so I don't know how easy it is to write combinator libraries in them. I do think it'd be hard without a static type system, however; combinators can have pretty complicated types, and I at least really want some machine assistance to check those types as early as possible. That said, the ones we used here weren't all that complicated.

      We definitely didn't really need the safety of wrapping side effects in monads, since we just used it for fresh labels. Didn't hurt that much either, though; programming an ant is naturally an imperative thing, so we'd have had to sequence commands in some way anyway.

      In general I agree that most of winning is about having the right strategy and being able to use your chosen programming language well.

      -- The "lump" in Dunkosmiloolump

    6. Re:Lisp results not very impressive by Pseudonym · · Score: 1
      It seems to me as though this would slow down the initial process of exploring the problem, as Paul Graham claims. Proponents claim that it makes up for that by making larger systems more reliable.

      But these contest entries don't ever become large systems, and the extra slowdown initially wouldn't have time to pay off in the long run if the long run is only 24hrs (or 72hrs).

      Personally, I find that the extra slow down in exploring data models and so on is paid back in less time debugging. (What a Lisp programmer might call "satisfying the whims of the type system" I find is better called "removing bugs which don't have to be tracked down later".) Moreover, once you've gotten the types satisfied, you can optimise your code and, thanks to type correctness, be pretty confident that you haven't inadvertantly broken anything. In the real world, of course, you'd have unit/coverage tests to ensure this for you. In a fast competition-like situation, you usually don't have time to write adequate tests, so getting the compiler to debug your code for you is invaluable.

      In the end, though, it depends on the programmer. Some programmers are careful, others are assertive. Dynamically-typed languages might appeal to careful programmers more than statically-typed languages, because it gives you a little extra freedom. Assertive programmers might prefer statically-typed languages because you maximise the amount of drudge work that you have to do, offloading more of it onto your compiler.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    7. Re:Lisp results not very impressive by Anonymous Coward · · Score: 0

      ignore the hype. Lisp is NOT all that. I've used it for a long time and even like it, but many advocates pump it up to be something it is not. There is no choice but to be let down when using it, because you expect so much from listening to the many snobs that use it.

      Even Perl consistently beat out Lisp. If you listen to the mantra of the Lisp crowd you hear only smart programmers use Lisp, or that it is a language for "smarter" programmers. Doesn't look like it to me. Either the language isn't all that or the programmer's aren't. Facts are facts.

    8. Re:Lisp results not very impressive by Devil's+Avocado · · Score: 1
      I'm not quite sure what to make of the underwhelming results of teams that use Lisp in these ICFP contests every year. Of course I can see that there are many ways in which the contest isn't a "fair" test of language against language. If one team has a dozen Inria guys whose full time job is OCaml development against another team with a single Lisp hobbyist, it isn't much of a fair fight.


      Funny, the winning team was a group of hobbyists and the team of INRIA guys (that included Xavier Leroy) finished 60th, though they did win the judges prize. Or did you mean that the INRIA guys were at a disadvantage because they had so much work to do outside of the contest?


      As for Lisp, I don't think it has any real advantages over modern functional languages like Haskell and Ocaml. Plus, it has the disadvantage of lacking a type system to help keep bugs out of your code.

    9. Re:Lisp results not very impressive by GCP · · Score: 1

      Or did you mean that the INRIA guys were at a disadvantage...?

      No, I meant advantage, which showed up this year in winning the judges' prize, but your point about how badly they lost objectively is a good one. I hadn't even noticed until you pointed it out. Odd that the judges would find them so cool if the actual results of their "cool" approach were so poor....

      --
      "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
  10. Comment removed by account_deleted · · Score: 2, Insightful

    Comment removed based on user account deletion

  11. Language of 2nd place entry. by hsenag · · Score: 1

    The 2nd place entry was actually a mixture of Haskell and C++. They used C++ for their simulator and visualiser, and Haskell for their ant assembler.

    1. Re:Language of 2nd place entry. by Anonymous Coward · · Score: 0

      The list of entries lists the language as just Haskell -- though this being the ICFP, I guess that's only natural. ;)

      Either way, the /. article's claim that it was "a program written in C++" is clearly ridiculous.

    2. Re:Language of 2nd place entry. by hsenag · · Score: 1

      They only had one space for a language there, so they picked the most important, I guess; probably the language most involved in the actual ant machine code generation. The actual declaration mentioned both Haskell and C++.

    3. Re:Language of 2nd place entry. by Devil's+Avocado · · Score: 1

      From what I heard it sounds like their entry was more Haskell than C++, and Haskell was more their tool of choice. During their acceptance speech one of them said, "I just want to apologize for the presence of C++ in our entry."

  12. The annual irony by Anonymous+Brave+Guy · · Score: 1

    There should be a new prize: Most Ironic Judges' Comment For The Year. I think this year's odds-on favourite would have to be:

    "Java and C++ are very suitable for rapid prototyping."

    :-)

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  13. Some reasons by notany · · Score: 1

    Maybe because all Lisp (at least Common Lisp) programmer teams equal in size and intelligence to winning OCaml-programmer team are busy working in Google?

    Or maybe because OCaml and other strongly typed languages attract the most intelligent people who have time to attend (read: academics love typesystems and clean functional languages, academics are smart).

    I strongly suggest that commercial Common Lisp vendors Franz and Xanalys should throw their programmers into next years competition. If developers of CL can't compete against developers of OCaml then we can see if CL is any good.

    --
    Dyslexics have more fnu.