ICFP 2001 Contest Results

Phil Bewig writes: "Results of the 2001 ICFP Programming Contest (previously mentioned at SlashDot here and here) have been announced. First place is to a program in Haskell, second place is to a program in Dylan, and the judges' prize is to a program in Erlang. The judges also named third place (ocaml) and fourth place (C) entries that were not awarded prizes. ICFP Programming Contest pages for prior years are available: 2000, 1999, and 1998."

Comments

The task

[damiam]

For those who don't want to click on all the links, the task was to produce a program that would optimise a HTML-like markup language called SML/NG. The programs had to remove excess whitespace, redundant and overlapping tags, and perform other simplifications.

Haskell, eh?

[PRobinson]

I've always wanted to get time to sit down and play with languages like Haskell, but never seem to get around to it. I think part of my hesitance (i.e. finding other things to do), is that I'm not confident that it's a commercially useful language.

The same goes for Erlang as well, which just seems to be an Ericsson R&D effort. In fact the only application I've seen written in the outside world in Erlang was Eddie and even that was an in-house Ericsson creation.

But then, the increase in languages has always confused me. When I was browsing through a bookstore one day I was amazed to see a book entitled 'REBOL for Dummies' - who, in their right mind, uses REBOL????

Re:Haskell, eh?

[cthugha]

I really recommend that you do sit down with Haskell. IMO, the judges were correct in naming it language of choice for "discriminating hackers". It has:

• clean, simple syntax (parentheses are used only to override default infix operator precedences, nothing more), including excellent list construction and comprehension;
• a strong object-oriented type system which ensures that the vast majority of coding errors result in a type error (although it can take a little while to get used to Haskell's type system);
• lazy evaluation of expressions: only the parts of your program needed to produce a result are evaluated, which allows you to write programs that left to run would produce infinite computations (e.g. programs to calculate the Fibonnaci series or the sequence of primes) and only evaluate them for the subset of data you need; and
• partially applied (or curried) functions: you really need to see these in practice, particularly in conjunction with the standard list-processing functions (e.g. map, scan, and fold) to understand their true power (the ability to create lists of partially-applied functions is very cool, although I have no idea how such things might be used).

With regard to your qualms about lack of use, I understand Ericsson have created their own functional language for in-house use (the name escapes me). Arguably, since we've all got oodles of processor power to spare, there's no reason not to use functional languages in the general applications sector, given their greater reliability.

If you want more info on Haskell, check out the official website (especially the Ode to Haskell on the humour page, which should give you an idea as to the language's feature set ;)). There you will find interpreters, compilers and other tools for a variety of platforms (incl. Windows and Linux) as well as complete documentation.

ICFP not a programming language comparison

[Anonymous Brave Guy]

Before everyone runs out and says "Haskell is the best programming language", as seemed to happen with things like OCaml in the past, please bear in mind that the ICFP tasks are somewhat biased toward functional languages. It is principally a contest for functional programmers, after all. This year's task, in particular, seems to be particularly suited to the built-in features of many such languages -- more so, perhaps, than things like the ray tracer task in the past.

It's to the credit of the coders that they produce such impressive results so fast, and it'll certainly be interesting reading when the full details are out. But let's not try to read too much into it this time, OK? Haskell is not suddenly a million times better than OCaml was last year, just because OCaml doesn't feature in the top list this time around. Functional programming still may not be the best approach for writing low-level instrument control code or operating systems.

So, before the millions of posts start arriving, I make a small plea: don't treat this as an objective (no pun intended) programming language comparison!

Re:ICFP not a programming language comparison

[Anonymous Brave Guy]

Functional/declarative langauges are great where bug-free precision is required because you specify what the results *are* rather than the steps required to produce the result. I'd feel much more comfortable with my mission-critical stuff written in Haskell than C/C++.

That's a fair point. Playing devil's advocate somewhat, I'll contend that a purely functional paradigm can be more awkward for certain types of job than a procedural language such as C. Note the number of "functional" languages that now offer heavyweight extensions beyond strict lambda calculus style functionality as a result. In those extensions is found extra power, but also some of the risks present in the other languages.

Being slightly more objective, I agree that for a 0% bug rate, C and C++ are not the solution (and I am a professional C++ programmer, so I have no axe to grind here). The catch is that most (not quite all) real-world programs can tolerate a 0.01% bug rate instead, and that can be reasonably achieved by a competent programmer in non-functional languages as well. At that point, the correctness argument loses a lot of its weight, and you have to consider many other factors as well. Like I said before, which language is most useful often depends deeply on the context in which it will be used.

Re:ICFP not a programming language comparison

[Blackheart2]

Boy, you sound nervous! If this were the "Object-oriented programming language contest," and C++ and Python and Eiffel won, I wonder if you wouldn't be saying just the opposite.

No one (at least, no one associated with the contest) is saying this is an objective comparison of programming languages or that the winners are the best programming languages for any and all purposes. Indeed, the prize-winners' appelations ("language for discriminating hackers") are so laughable, no one in his right mind would take it seriously.

This contest is about having fun, taking pride in your favorite language, giving a few kudos where they are deserved, and a little bit of advocacy for a class of programming languages that are overlooked by the programmer community at large. It's not a pissing contest.

BTW, what is an "objective" language comparison anyway? I am a programming language researcher, and I can think of a few theoretical ways to compare programming languages, but I would think that most programmers-in-the-trenches would be more satisfied with tests that compare languages on real life problems, and these contest problems are not far off from that. So what are you so unhappy about?

Re:ICFP not a programming language comparison

[mikera]

Yeah, I totally agree that you should pick your langauge based on the context. I know enough different languages not to really care which one I use, so it usually comes down to who else will need to maintain the code (Java often wins in this regard....). I can live with 99.999% success rate, though some might regard that as heresy :-)

Interestingly, I *used* to think that pure functional languges were inconvenient, particularly for stuff like IO and user interfaces.

I have now changed my opinion after investigating a concept called "Monads". These are seriously cool, they are an abstract data type that effectively descibes an "operation". They basically allow you to capture procedural/OOP type concepts of state, communication etc. in a purely functional manner.

Techniques like this may be the key to achieving the best of both functional and procedural/OOP worlds. You get all the accuracy and development speed advantages of functional languages, but gain the ability to manipulate state and interact with the world in a procedural style.

Extremely cool, though it's a tricky concept probably best left to computer scientists and the more hardcore coders....

Different ways of scoring

[Anonymous Brave Guy]

Just found this interesting analysis by the captain of the highly-placed Dylan Hackers entry. He uses his own sensible-sounding criteria for rating the entries, obviously somewhat different from the real judges', but not so far off in final results. It makes for an interesting alternative perspective.

BTW, after I earlier posted that this shouldn't be taken as a fair comparison between programming languages, this information shows exactly why. The top entry is written in C++, and didn't figure in the "big five" mentioned by the judges of the real contest. In other words, the languages coming out on top change significantly, based on two different, but both reasonable, methods of ranking the entries.

Dylan

[Earlybird]

Dylan is a lovely, lovely language. At times awfully verbose in a way that reminds me of Ada, but its syntax and design is different. Its design is consistent and thoughtful, and the language is blissfully free of the cruft we see in C++ and Java.

For example, Dylan's syntax is based on whitespace; so identifiers are permitted to contain most characters except whitespace and punctuation. (The downside, of course, is that you must type spaces around most operators. However, any character can be escaped with \, and you can even reuse reserved words this way.)

This flexibility gives you a lot of freedom. For example, the official convention uses dashes to separate words; methods/functions that return a boolean value ends with ?; globals are surrounded by asterisks; and types are surrounded by angle brackets. So a method may be named is-camera-on?(), a global may named *game-clients*, and a class may be named <socket-server>.

Dylan provides other small, but distinctive, features. For example, it supports per-file metadata: Any source file can start with an RFC 822-like header, which you'd typically use for version, author, copyright, license and documentation data.

Of course, I haven't even started on the language features. Dylan has an interesting, elegant object model. It has explicit support for "slots", analogous to Delphi's class properties: data members whose access is delegated to accessor methods. It has explicit support for singletons and generic programming. It has multiple inheritance. It has garbage collection, type safety, a modern module system, etc. Dylan is usually compiled, but can be interpreted. Its extremely dynamic nature means that method dispatching and "smart linking" can be a complex affair; this is a weak link, and at least for Functional Developer (formerly Harlequin Dylan), program efficiency is dependent on the compiler being able to do "whole program" analysis.

However, I would hesitate to call it a functional programming language. According to the Dylan reference manual, "Dylan is a general-purpose high-level programming language, designed for use both in application and systems programming". It is a structured programming language belonging to the same paradigm as C++ and Java. There are clear signs of having been influenced by functional programming, though.

The name "Dylan" does not come from Bob or Thomas, but from the phrase "dynamic language".

For more information, I recommend the Functional Objects site. They provide a Windows/Linux-based IDE and compiler for Dylan. The "Basic Edition" is free as in beer.