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

Comments

My Java Bubble

[fragmentate]

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.

Re:My Java Bubble

[sammy baby]

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

If the one you forget is English, you'll know you've hit burn out.

Re:My Java Bubble

[TheRaven64]

I'm not a huge Haskell advocate - it was my first introduction to functional programming, and it made me hate FP for a few years. More recently I've started using Erlang, and it's a joy to use - a functional language designed by pragmatists rather than theoreticians. It also has the best syntax I have yet seen for handling distributed programming - process creation (local and remote) and message passing are built into the language.

As someone who liked prolog, one of my favourite parts is the pattern matching. This can be done on any data type, including binaries (bit fields), so you can have a function for parsing a datagram, and a different definition for each packet-header - and all you need to do is define the part that is constant in the function header then the remainder of the processing in the body, and write a different body for each packet type.

Re:My Java Bubble

[Haeleth]

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

Re:My Java Bubble

[brucehoult]

And how many total programmers are using Dylan in this contest? :)

Not many. Just us. Unfortunately most people have not yet heard of the Dylan programming language.

Otherwise, you'll have severe selection bias - especially in contests with such a small number of Dylan users, but even if there were more. Really, contests like this are pretty useless for language evaluation - only individual-evaluation

I guess I'll have to take that as a compliment :-)

I agree that contests such as this can't prove that some language is superior to others since, yes, it is possible (though very unlikely!!) that I and my friends are all super-geniuses who could do equally well using Brainfuck or INTERCAL.

What it does prove though is that there is nothing seriously wrong with Dylan that would prevent you from using it to write a complex program very quickly, in a situation requiring high performance and absolute correctness. I don't know if you read the rules, but if a program ever crashed, or took more than 5 seconds to respond to the server, or responded with an illegal message then it was instantly out of the entire contest. That's what happened to the vast majority of C and C++ and Java programs, and that is what always happens to them.

and even that, only after a significant number of contests have been completed by the participants.

How many is significant? A Dylan entry has won prizes in each of 2001, 2003 and now 2005, despite there being only one Dylan entry each year up against hundreds of entries in other languages.

You can choose to think that my friends and I are geniuses, or you can think that maybem, just maybe, there's something worth investigating in this Dylan thing.

Re:My Java Bubble

[Rei]

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

API piggybacking...

[irritating environme]

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!

Bobby

[DysenteryInTheRanks]

I have only one question for developers programming in Dylan: How does it feeeeeeeeel?

Re:Bobby

[Soko]

To be on your pwn... With no direction $HOME...

Soko

Re:Bobby

[Profane MuthaFucka]

I'll try bash.
$ like a rolling stone
-bash: like: command not found

Hmmm, that don't work. How about gcc.
gcc t.c
t.c:1: error: syntax error before 'a'

Oh, it must be c++
g++ t.c
t.c:1: error: 'like' does not name a type

Um, python?
python t.py
    File "t.py", line 1
        like a rolling stone
                  ^
SyntaxError: invalid syntax

No good. What else can I try? Wait, PERL!

perl t.pl
I love that song, but I can't locate object method "rolling" via package "stone" (perhaps you forgot to load "stone"?) at t.pl line 1.

At least someone remembers Dylan.

Re:Bobby

[Matthaeus]

What version of perl are you using to get that error?

And how many of the rest of you actually tried it out?

Programming

[bulio]

Pretty awesome, I wish I could program. Problem is, everytime I attempt to learn a language, I can learn the basics (Variables, print, etc.) then I get lost when it comes to actually writing anyhting at all. I need to find a decent language to try that is easy. (Besides ruby and python, tried em)

Re:Programming

[bulio]

oh, I know, Its just that I wish programming in general could be a bit simpler to learn (I've read books, tutorials, the whole thing).

Re:Programming

[Radres]

Don't bother learning; just send your desired programming task overseas.

Re:Programming

[Vengie]

Variables! Heathen! Loops? Sloth! Tail recursion? Vanity!

Re:Programming

[Rei]

The language isn't the important thing, although you should of course start with an easy language (like BASIC - **not** Visual Basic, or anything like that, mind you. Also, if you do use BASIC, try to use a version of it that has true subroutine calls). Don't worry about the capabilities or performance of the language - your only concern at this point should be how *simple* it is for a beginner. You have to learn the basics of programming first; don't worry about a do-it-all language.

Second, have a grand overarching goal in mind, but choose *ridiculously easy* programs to start with. Start with "Hello World". Move on to some variable assignment and looping. Learn arrays, and work them in. Then, move on to things like simple sorting algorithms, lookup tables, etc. These may not be the most fun to write, but they'll get you comfortable with programming.

When you want to start with things like graphics, again, *keep it easy* (again, a language like BASIC would be good - you don't want to be messing with GL or any window API functions at this point). A good starting graphics program is to make it snow, one single-pixel snowflake at a time, with the snow falling top to bottom and not sticking around. Then, steadily improve the program - have multiple flakes fall at once, have them blow randomly in the wind, use more than a pixel for them, have them accumulate at the bottom, etc. Fractals are also often good starting graphics programs. A neat iterative fractalline program involves taking any image, and XORing it with itself shifted a couple pixels in direction, the direction being determined by looping through preset directions that sum up to zero (example: [(-1,-1), (2,-1),(-1,2)]); you get strange ghostlike images resembling the original pop back up later as things fade to static.

From thereon, you should start getting frustrated with the lack of power and performance that your starting language has. What language you move onto is, of course, a contentious issue; however, a general, *very rough* guideline is that you want languages like python and perl for writing programs that "get stuff done for you", while you want languages like C/C++ and Java for programs that "you run and interact with". This is, of course, an extreme overgeneralization, but there's some truth to it in practice.

Don't get obsessed with "learning the language". Learn what you need from it. I'll put it this way - in college, I took one course on compilers and interpreters; everything in the course was done in 'scheme'. The first week was spent learning the language - one week, thats it. After that, we worked on the course material.

When you have time, and you're already comfortable with what you do know, learn more. Things to especially focus on are things related with programming styles, reducing maintenance, and enhancing clarity - for example, if you learn what you need in C++, when you have a chance learn about templates, vectors, maps, the importance of const, etc.

When you feel comfortable with your programming abilities, contribute to an extant project. Don't jump in and tell them how things should be, however - find out what *they* want done, and do it *their* way. Learning how to program in collaborative efforts is very important.

Re:ICFP

[The Wookie]

There was no requirement to program in a functional programming language. One guy wrote his cop & robber as shell scripts, although it failed in both rounds.

Re:ICFP

[putko]

You can use imperative languages too. That's the neat thing about the tournament -- given a choice, most of the folks choose languages that offer more expressivity than the typical imperative language.

There have been "C" programs that won previously, I believe.

Motivation

[Acius]

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.

Re:Motivation

[gb506]

I find it's more about motivation than picking a language or how hard it is.

By the looks of our IT dept, exercise and laundry must require a lot more motivation than leaning a programming language... Nyuk, nyuk, nyuk.

Re:ICFP

[Fahrenheit 450]

The ICFP contest accepts submissions written in any language. In this year's contest, there were 34 C++ entries (the most of any language), 20 Python, 19 Java, 10 C, and 9 Perl entries -- of the "functional" languages, there were 21 OCaml entries, 16 Haskell, and a mishmash of "others" like Dylan, Erlang, scheme, etc.

Re:I can see literally see my house from here.

[Radres]

"it seems like you're developing AI for an RPG."

Awe, you sound like Clippy when you talk like that!

Can't help myself

[theskipper]

Gosh Wally, Haskell gives me the creeps.

How To Design Programs

[GileadGreene]

As others have said, the problem is not languages. However, rather than offering vague suggestions about "motivation" or "picking a goal", I have some concrete advice: try taking a look at How to Design Programs. It's textbook by some of the best minds in CS education, and its goal is to teach you how to break down and structure problems, and create programs which solve those problems - not just to teach you a language. It'll teach you to think like a programmer. Which, quite frankly, sounds like what you need. Better yet, it's freely available online (so you can easily give it a testdrive), although I'd recommend picking up the print version if you decide you like what they have to say (for the sake of readability if nothing else).

Try Q!

[agg-1]

Shameless plug: Those of you who like Erlang might also wish to give Q a try. http://q-lang.sf.net/ Pattern matching is at the heart of the interpreter, as the language is based on general term rewriting instead of the lambda calculus. Fairly pragmatic language as well (interpreted, dynamically typed). Comes with a system interface, XML/XSLT support, Apache module, OpenGL interface, modules for doing computer music and multimedia stuff etc. Q still has still to prove itself on something like the ICFP programming contest, but it's quite usable already (IMHO).

Syntax versus Logic

[ari_j]

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.

Watch a game in action

[gringer]

Here is a graphical simulation of a game that was played. The red guy is the robber, and the blue guys are the cops. There's a key available if you want a better idea of what's going on.

Re:contest is somewhat biased?

[sydneyfong]

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

Re:No SCHEME?

[The Wookie]

They don't have complete per-language statistics. I grabbed all the team descriptions and massaged the data a bit to get a complete list. I merged Moscow ML, SML and SML/NJ. There was one entry that listed Scheme as the language. Ironically, the Dylan Hackers appear to be the only team to have used Dylan. I am one of the 21 ocaml people (O Caml, My Caml). My robber screwed up while bribing a cop in the twisted round and didn't get to the playoffs. These statistics are just for the main implementation language:

34 c++
21 ocaml
20 python
18 java
16 haskell
10 perl
10 c
6 lisp
5 sml
4 c#
3 ruby
2 freepascal
1 visual basic .net
1 swi-prolog
1 shellskript
1 setl
1 scheme
1 refal+
1 nemerle
1 modula-3
1 mercury
1 javascript
1 erlang
1 eiffel
1 dylan

Previous winning languages

[Fahrenheit 450]

2004:
Judges prize: OCaml
Lightning division winner: Java, C++, Perl, and m4
Main division: (1st) Haskell, (2nd) Haskell and C++

2003:
Judges prize: C++ and Dylan
Lightning division winner: OCaml
Main division: (1st) C++, (2nd) C++, (3rd) OCaml

2002:
Judges prize: Python
Main division: (1st) OCaml, (2nd) C

2001:
Judges prize: Erlang
Main division: (1st) Haskell, (2nd) Dylan, (3rd) OCaml/C (a tie between two teams)

2000:
Judges prize: SML
Main division: (1st) OCaml, (2nd) OCaml, (3rd) Haskell, (4th) Mercury

1999:
Judges prize: Haskell
Main division: (1st) OCaml, (2nd) Haskell

1998:
Judges prize: J
Main division: (1st) Cilk, (2nd) OCaml