Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

ICFP 2004 Programming Contest Results 30

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

ICFP 2004 Programming Contest Results More

ICFP 2004 Programming Contest Results

Comments Filter:

  • 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 :)

    • Re:Lighting division (Score:2, Informative)

      by GigsVT ( 208848 )
      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 don't know about you, but I, for one, was antsy to see the results!

  • Visualizing the winners (Score:5, Interesting)

    by TheRealFoxFire ( 523782 ) on Tuesday September 21, 2004 @08:48AM (#10307238)

    For those of you who want to see the winners in action, the Formicidae simulator from Ant Wars [ant-wars.com] 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 [ant-wars.com]
    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.

    • "Already?" (Score:3, Insightful)

      by Lucas Membrane ( 524640 )
      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"?

      • Re:"Already?" (Score:3, Interesting)

        by TheRealFoxFire ( 523782 )
        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.
    • 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 woul
  • Dylan language had some strong entries in previous years, and now it's presently absent 100% from the results. What gives there?

    • Re:What happened to Dylan? (Score:5, Interesting)

      by brucehoult ( 148138 ) on Tuesday September 21, 2004 @07:07PM (#10314102)
      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!
  • ,,,bestows on the winners unlimited bragging rights.

    That almost makes entering worthwhile ...
  • 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 fo
  • Im proud to have the best score Java ant ;) 32th place :(

  • Lisp results not very impressive (Score:4, Interesting)

    by GCP ( 122438 ) on Tuesday September 21, 2004 @06:08PM (#10313551)
    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.

    • Re:Lisp results not very impressive (Score:4, Insightful)

      by John Meacham ( 1112 ) on Tuesday September 21, 2004 @07:05PM (#10314082) Homepage
      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.
      • 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
        • 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

        • 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

    • Re: (Score:2, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • 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.

    • Re:Lisp results not very impressive (Score:4, Interesting)

      by brucehoult ( 148138 ) on Tuesday September 21, 2004 @07:46PM (#10314419)
      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.
    • 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 C
    • 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

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

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

Slashdot Top Deals

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Close