Slashdot Mirror


ICFP 2005 Programming Contest Results

Fahrenheit 450 writes "The results of the The Eighth Annual ICFP Programming Contest are in, and it looks like this was the year for Haskell and Dylan, with Haskell programs taking first & third prizes, and Dylan claiming second prize and the coveted Judges' prize. This year's contest was a simulated game of cops and robbers, with a twist to the rules thrown in after the participants had submitted their initial entries. Step through the transcripts of the contests or just download the PDF version of the presentation slides and tell us all how you could have wiped the floor with the winners using your carefully crafted COBOL or awk submission."

7 of 111 comments (clear)

  1. My Java Bubble by fragmentate · · Score: 4, Insightful

    It's amazing how many programming languages there are. I would never have thought that Haskell and Dylan would have even placed.

    I've been in a Java bubble for far too long. Time to burst that bubble and look into things like Ruby, Python, etc. I know they're not new languages, but it seems like once you get buried in Java, Perl, C, or PHP it's hard to escape.

    On the other hand, my mind is like a FIFO -- in order to learn another language, I have to forget one.

    1. Re:My Java Bubble by Haeleth · · Score: 2, Insightful

      I would never have thought that Haskell and Dylan would have even placed.
      I've been in a Java bubble for far too long. Time to burst that bubble and look into things like Ruby, Python, etc.


      Given the context in which you're deciding to look outside your box, don't you think Haskell or Dylan might be more appropriate languages to look into? :P

    2. Re:My Java Bubble by Rei · · Score: 2, Insightful

      possible that I and my friends

      *Exactly*

      You just perfectly demonstrated selection bias. From a random sampling of the world's programmers, what are the odds that both you *and* your friends would be selected?

      despite there being only one Dylan entry each year

      *Exactly* - you're doing a good job summing up my points in your post. With how many total Dylan programmers? You and how many friends? This points to the much more likely conclusion, that you and your friends are good programmers when it comes to these kinds of challenges.

      Please understand the difference between "me and a couple friends" vs. "a sizable group of people with no correlation to each other, or to their programming skill levels." If you want commentary on the language, you need to take programmer skill out of the picture. You need a sizable sampling of Dylan entries, and you need to have the selection of Dylan not based on anything that would correlate to how good of a programmer the person is, or how the challenges correlate to what they've worked in (for example, if mechanical engineers who hate computers tend to program in Language A, and CS PhD-holders who've worked in industry for a decade tend to program in Language B, that would be a huge disadvantage to Language A; on the other hand, if the challenge was "write a piece of software that models fluid flows", Language A will suddenly get a ratings boost that has nothing to do with how good it is).

      --
      ... in Siberia, where Putin killed a fish with a speargun. He later claimed it was killed by Ukrainian separatists.
  2. API piggybacking... by irritating+environme · · Score: 4, Insightful

    That's why many newer languages piggyback on the Java api set (Jython and their ilk), since the real bother isn't learning the core language features, it's learning the gigantic libraries that accompany them:
    - UNIX-derived C libraries
    - C++ template libraries
    - unending Perl libraries
    Java offers a quick-and-dirty crossplatform API for these languages that handles most of what they need, if they can wrangle their language semantics and don't mind the larger memory footprint and bytecode.

    Also, if they can compile to bytecode, that helps automagically close some of the interpreted vs. compiled performance gap due to the hotspot compilers and java interpreters.

    Go go java hate mail!

    --


    Hey, I'm just your average shit and piss factory.
  3. Motivation by Acius · · Score: 2, Insightful

    I find it's more about motivation than picking a language or how hard it is. If you've got some mental image of "I want to write Quake!" (or hopefully something a hair less ambitious), then it gives you both a reason and a direction for what you're trying to learn. Then you can obsessively search the web for tutorials on the different bits and pieces you think you'll need until you have a fairly decent subset of the skills needed to reach your dream. Learning the language is a free side effect.

    --
    Acius the unfamous
  4. Syntax versus Logic by ari_j · · Score: 2, Insightful

    What you are failing to do is not learn how to program, or learn a language. What you are failing to do is understand how to think logically and then turn your thoughts into code. Every language is the same - pick one and learn how to write algorithms instead of just lines of code.

  5. Re:contest is somewhat biased? by sydneyfong · · Score: 2, Insightful

    Look at it in another way. Apparently from the name of the contest they focus mainly on functional programming languages. It is therefore natural that they would be inclined to pick AI-ish problems that are more suitable for functional programming. I believe it wasn't a (conscious) intention that they allowed other languages in the contest for the purpose of tilting the playing ground to their (functional programming) favor. If you think about it, ICFP problems might be fun even for those who prefer an imperative language, and excluding them would be a lose-lose situation: the contest gets fewer contestants, and those who want to participate, couldn't.

    And for your last question, probably not. It seems that many slashdotters would prefer "real" problems in contests than "hypothetical" ones. But there are reasons why there aren't many of these "real" problems.

    First, "real" problems usually contain sub-problems that are tedious and a PITA to solve. (Think writing an OS like Linux - I've heard that making things work on a dozen different architectures and working around crappy hardware is a nightmare.) Besides, most people have enough of "real" problems to solve in their normal lives, may it be work or study. "hypothetical" problems tend to be fun, for the same reason people spend time playing MMORPG.

    Second, "real" problems tend to have quite a bit of economic value, and once you get to the situation where you can get people to attempt solving your "real" problems, you wouldn't want a dozen of developers working on the same thing (to illustrate, think about GNOME and KDE - there has been criticisms that effort is diverged and distracted with merely two projects, and to think of holding a competition where all contestants write the same fscking thing and duplicating the effort many many times?). And when you come to realize this point, there's a very fine line between a "real problem contest" and a bounty like those of Google, GNOME and other OSS projects.

    And really, if you want a contest of "real programming problems", just go out and find a good job, (or even start an OSS project and see whether somebody awards you with something ;-p), and try to achieve whatever you aim to be. If you really want a "contest" feel, you might want to take upon the motto of "He who dies with the most toys, wins" ;-p

    --
    Don't quote me on this.