Saturday, July 28, 2007

ICFP Contest Losing It's Functional Nature?

When I first participated in the ICFP Contest last year I was expecting an AI problem from looking at previous years. I was attracted to the contest because of this. My team had won the Java Challenge (renamed the Parallel Challenge for that year) in the ACM ICPC the previous year, so I thought it would be nice to try out the longer version.

So I got a team together telling them to expect some AI. None of us knew any functional programming and although we could see from previous years that it was beneficial we weren't taking it seriously. We get the problem and boom, "code a VM". Ok, where's the AI? We immediately jumped in with C++ and even then we initially had efficiency problems, although those were quickly rectified. Everyone complained afterwards that functional languages lost out there.

Then the mini problems started revealing themselves one by one. I will admit we didn't get very far with them (mainly due to factors out of our control and a lack of interest from some who expected an AI problem). Some of the problems were slightly functional in nature, but I still don't think there was any major benefit in using a functional language.

After the lack of AI in 2006, I was able to gather some people into the team that previously wouldn't participate because of the AI nature in the past. This year we were far more prepared for a non-AI problem. I also got a larger team together after 2006 being multiple small problems. Once again, none of were functional programming gurus (although by now I have at least know a bit of Haskell).

We get the problem this year and once again it starts off with a VM (DNA->RNA). With most of our team being C++ fanatics, we quickly got it running and even discovered ropes pretty quickly. From reading other peoples comments, the functional languages suffered with the VM. Although it was possible to get an efficient VM, the sub-linear data structures appear to be fairly uncommon. Yes, they're not that common in C++ either, but the functional teams sure seemed to rush over to C++.

Then there were the problems once you've passed the VM. Our team used Perl, Python and a bit of Bash to glue the scripts together. I don't see how a functional language could have been beneficial in any way. Even if someone does find a way of using a functional language, I sure would like to see how functional languages can do a better job.

The idea of the ICFP Contest is to promote functional programming. Or at least, that used to be one of its goals. Has this emphasis changed? There sure still seem to be many teams whose primary tools are functional languages. Last year, none of the top three teams nominated a functional language as their primary tool. I'm confident the same will occur this year.

I certainly do not mean for this to be an attack on the contest. I still love it. This is just something that has been on my mind making me wonder what the connection to the ICFP is. Is it possible that the functional programming community can learn from the lack of results from functional teams and make the functional languages more powerful? Maybe that's the aim?

8 comments:

  1. The point of the ICFP contest is not to pick a functional programming orientated task, and then compete to see which language does it best. The purpose is to pick a task which is just a language neutral task, and then people can try whatever language they want.

    The ICFP contest organisers don't have the ambition of rigging the contest, its meant to be fair. Although it does seem like the last few years have been heavily biased towards C/C++, since VM's are typically done in C.

    ReplyDelete
  2. That's interesting to hear. I've always thought that the idea behind the contest is to attract people to functional programming. The 2004 and 2005 contests are definitely more weighted towards functional programming.

    I have no concerns about rigging, but am rather trying to get an understanding of where the contest is heading and how the functional programming community benefit.

    ReplyDelete
  3. This year's ICFP contest was quite definitely geared toward functional programming in the concepts. If functional programmers abandoned their tools and used C++ instead, then fine -- Maybe it was a good decision. Still, the DNA -> RNA conversion had all sorts of neat links to lambda calculus. As part of my team's final effort, I even wrote a fix-point combinator in Endo DNA!

    So I think the contest did an excellent job of remaining language-neutral, while still remaining true to the functional roots of the ICFP in the spirit of the task.

    I could complain about this year's ICFP, but I wouldn't start by saying it wasn't functional enough.

    ReplyDelete
  4. I hear what you say, but consider someone who knew say Haskell and C++ equally well. Which language would you think such a person would use mainly in solving this problem?

    ReplyDelete
  5. I guess I can just speak from experience. I know Haskell and C++ about equally well (and Java better than either). I chose to do it in Haskell. While I did have performance problems, I never had any reason to believe they were due to using Haskell instead of C++. I know my Haskell code (even after I fixed the performance by discovering Data.Sequence) is far shorter and easier to understand than it would have been in C++.

    In any case, the bigger point was that there are other (and better) ways for ICFP to be connected to functional programming than to blatantly favor them in the problem itself.

    ReplyDelete
  6. That's good to hear and I hope that holds true for most people in such a situation. Without much knowledge of functional programming it's nice to hear that they didn't lose out. It certainly encourages me to further learn functional programming.

    ReplyDelete
  7. The efficiency of functional languages should not be underestimated. I had a very naive Haskell implementation which did over 23k iterations per second. There was another Haskell implementation breaking 40k. Both are on unremarkable machines (mine is a small intel mac mini). I'm far better versed in C++ than Haskell, but looking back, I would have ran into problems with C++ during the refactor-and-cleanup phases of the programming.

    ReplyDelete
  8. Um... 2d isn't functional? Since when?

    ReplyDelete