ICFP 2002 Contest Winners Announced

Georgwe Russell writes "The Winners have been announced at the official web site. Looks like OCaml and functional programming have won again, with the 3 member TAPLAS team. There is somewhat of an upset, though. Second place goes to 3-member team Radical TOO, whose entry was written in C! In the lightning round, the virtues of Python as a quick prototyping language were shown in the lightning division's winning entry by the OaSys one-man team. Does the skill of the programmer prevail over the limitations of the language and paradigm used, or is C nearly as good a language as OCaml?"

Comments

Re:What's wrong with C?

[Gekko]

The contest was a fast prototyping contest. You had 72 hours to complete the contest. Ocaml's strong type checking and garbage collection can make a big difference.

Of course an excellent C programmer, with excellent tools can prototype fast, but they have to have more domain knowledge and a more intimate understanding of their language.

From the contest web site.
"correctness, algorithmic cleverness, and performance will matter"

Re:Language doesn't matter, language CLASS matters

[jbrandon]

OCaml is functional, you give the computer rules and then point it in the right direction.

That's not what "functional language" means. The magic of functional programming comes from the (sometimes typed) lambda calculus, in which functions can be passed as parameters. In this vein, we also have easier polymorphism (functions can take a type as a parameter) and fewer "side effects," which could mean fewer bugs.

See Why Functional Programming Matters. For the theoretically inclined, I enjoyed An Introduction to Polymorphic Lambda Calculus with Subtyping.

(Both links can be found on the pages I link to; I don't link to the articles because I don't know your document format of choice.)

Ability, luck, and language -- in that order

[tmoertel]

Programming ability almost always dominates all other controllable factors, including choice of programming language, when it comes to most programming tasks.

Simply put, programming languages are tools. Some tools make certain jobs easier than others, but tools only go so far. The rest is up to the programmer.

In the case of this year's ICFP contest, Team Radical Too did well because they had a good strategy that ultimately fared well in judging. Their robot performs a semi-exhaustive simulation of the possible moves up to a certain degree and then chooses the best move based on the simulation results. (It's a cool approach, and the source code is worth a read.)

It's a compute-intensive strategy, and my guess is that they selected selected C as their implementation language for this reason. They made the decision to sacrifice the high-level flexibility that other languages provide in order to have C's low-level control over how CPU cycles and memory are consumed.

Oh, and then there's luck

Despite how much we like to argue about programming ability and choice of programming language -- and competitions are perfect fuel for this particular fire -- we shouldn't read too much into the results of programming competitions. Luck plays as large role as any.

I returned, and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favour to men of skill; but time and chance happeneth to them all.

In the case of the 2002 ICFP Programming Contest, for example, I happen to know that several of the robots, including Team Radical Too's robot, will unwittingly commit suicide in situations where they have the opportunity to push another robot into lethal water that spans more than two board cells. In this situation, the attacking robot will push its victim into the water, killing it. The victim, although dead, appears on the game board the next turn (and is removed from the game on the turn after that). However, the attacking robot's logic fails to account for the fact that dead robots can remain on the game board for a turn before they are removed by the game server. It considers any robot on the game board to be alive -- including the now-dead victim, floating in its watery grave -- and hence fair game for attack. Seeing that there is water beyond the now-dead victim, the attacking bot will try to push it again, thus stepping into lethal water itself and effectively committing suicide. Oops.

Luckily, the judges didn't have any wide spans of water in the map used for the final showdown.

Indeed, chance happeneth to them all.

From what I saw, it went like this . . .

[tmoertel]

I am at ICFP this week and was at the presentation of the contest results this afternoon. The judge's scoring method, iirc, went like this:

1. All of the robots were subjected to a battery of solo games and games against reference robots provided by the judges
2. The twenty highest-scoring robots went to the second round and played a number of games against each other.
3. The eight highest-scoring robots went to the third round and were subjected to further games.
4. Finally, the top two robots battled on symmetrical maps with each being allowed to start from the various starting points an equal number of times (to rule out starting-point bias).

The judges indicated that they would be posting more information later. The conference is still going on (in fact, ICFP is part of PLI, which is going on through 8 Oct), so give the guys a chance to get home and write something up. You'll get the details in due time.

Are you sure you don't have it backward?

[tmoertel]

The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.

Are you sure you don't have it backward about the amount of time it takes to write software in functional languages? Most of the people I know who are good programmers of both functional and imperative languages consider the former to be considerably more efficient when it comes to programmer time. My experience with functional vs. imperative languages has certainly shown this to be the case. Likewise, industry groups that have made investments in functional programming have found significant increases in programmer productivity.

But don't take my word for it:

• Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
• Four-fold Increase in Productivity and Quality: Industrial-Strength Functional Programming in Telecom-Class Products (PDF) Abstract: The AXD 301 ATM Switch is the flagship in Ericsson's line of Datacom products. A fault tolerant and highly scalable backbone ATM switch, AXD 301 has enabled Ericsson to take the lead in the migration of public telephony networks to becoming true multiservice networks, offering both quality voice and broadband data services on the same backbone.... This paper demonstrates how the development of such systems is supported by the Erlang/OTP technology. The Erlang [functional] programming language was developed by Ericsson specifically for the purpose of building fault tolerant, distributed and complex systems.... The paper demonstrates how Erlang supports the characteristics mentioned, while offering unusually high productivity.
• Haskell vs. Ada vs. C++ vs. Awk vs. ... : An Experiment in Software Prototyping Productivity: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
• Functional languages in microcode compilers (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.

You can find more such papers by tracing references and by reasonable application of Google and CiteSeer.