Slashdot Mirror
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.
It is completely alien to those people who are used to C/Perl/Java/Basic type languages, it is obsessively recursive (which scares a lot of people).
It also by default uses whitespace to determine nesting, and HUGS (the compiler we use) gives error messages that look like garbage: complaining about unexpected brackets when there are no brackets in the whole program (the brackets are implied by the whitespace).
The combination of an eccentric compiler and the fact that Functional languages are 'alien' makes most of us hate Haskel and most 'Hackers' would rather shoot themselves or use Visual Basic than use Haskel.
BUT if you can cope with recursion (which you should) and are willing to forget a lot about 'normal languages' and learn functional languages, (HUGS is fine too once you get used to it and is free so its unfair to complain), then Haskel can produce beautiful simple concise programs and 5% of the course love it (those that know how to use it - you might even call them software engineers [not hackers]).
-I should be working but I doubt my license is valid.
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....