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."
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????
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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....