Slashdot Mirror


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

22 of 252 comments (clear)

  1. Yeah.. language is not matter much.. by WetCat · · Score: 5, Interesting

    The proficiency in writing programs means more.
    Most languages are functionally equivalent,
    you can even have something like Alma :
    a program that translate a lot languages to a lot of other languages. It's fun to play with it!

  2. It's the Algorithm, Stupid by null-und-eins · · Score: 5, Insightful

    This year's ICFP task, as well as last years, was all about finding a good algorithm. More than anything else, knowing the domain would help. Of course, using a language that provides strong typechecking (like OCaml) or garbage collection (OCaml, Python) allows a programmer to concentrate on the main task. You should not draw too many conclusions from the language that was used for the winning entries.

    --
    At the beginning was at.
  3. I guess I'm not a real geek afterall by mao+che+minh · · Score: 4, Funny

    I have no clue what the hell any of this is about.

  4. What about #3-160? by spRed · · Score: 3, Informative

    Shamefull vanity, but I'd like to know how I did.
    Radical Too (runner-up) was kind enough to post their source (after the competition is over, there isn't much reason not to).

    But what about me (Aqua Team Hunger Farce)?

    Links to source/explanations of many entries can be found on the ICFP site Here

    My entry is listed as well. The order of listing is just when people submitted links to writeups, not the winning order.

    --
    .sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
  5. Re:What's wrong with C? by Gekko · · Score: 4, Informative

    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"

    --
    I mod down any one who says "I'm sure I will get modded down for this"
  6. C is a gr34t langu4g3! P1eese k33p u5ing it!!! by Anonymous Coward · · Score: 3, Interesting

    We love the way C makes you think about all those little details like strings and bufsize and pointer math. It means we get to keep 0wning you, because you can't get it right.

    Don't get me wrong; C is great for the kernel and other code that needs to be machine-layer portable. But with the gnome panel at 5 mb, apparently no one cares about writing tight code anymore. So if its not going to be small and fast, it might as well be secure and reliable.

    Which C will never be.

  7. Re:Language doesn't matter, language CLASS matters by jbrandon · · Score: 5, Informative

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

  8. Ability, luck, and language -- in that order by tmoertel · · Score: 5, Informative
    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.

  9. More lines in C, but same outcome. by wackybrit · · Score: 5, Interesting

    It's all quite an easy debate really. Some people prefer higher level languages like Python, whereas some prefer lower level languages like C.

    What's the difference? The amount of lines you need to write to get the same result.

    It therefore goes that the more lines you need to write to get the same result, the more control you get over the program and the computer on which it is running. This means that programs in C can control the computer in better ways than programs written in Perl or Python.

    A lot of programmers, like C programmers, think that C, much like Ada, a language to program, in on problems such as objective and the logical ones. An interesting example is the difference between Visual Basic and Visual C++.

    In Visual C++, to open a window takes about 104 lines of code if you estimate the number without doing any research like myself. In Visual Basic, you can open a window just by creating a new project and hitting 'Run'. It's easy, and that's why it works.

    This is primarily true in the first instance, since there is proof that indicates such, although there is no evidence of this to suggest quasi-otherwise.

  10. Re:Language doesn't matter, language CLASS matters by moebius_4d · · Score: 3, Informative

    Hello? If you use C++ and don't know about Boost, you've been living in a cave. Come on out and see, it's really cool. Also check out Modern C++ Design by Alexandrescu.

  11. From what I saw, it went like this . . . by tmoertel · · Score: 4, Informative
    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.
  12. Good programmers win by gmarceau · · Score: 3, Insightful

    Winning the contest is more about being a good programmer than about the particuliar programming languages.

    But then again, you can assume a good programmer would pick a good programming language.

    --
    This post was compiled with `% gec -O`. email me if you need the sources
  13. What's this? by gmhowell · · Score: 5, Funny

    whose entry was written in C!

    I was just getting used to C#, now we are added C! ?

    How is that pronounced? 'see bang'?

    How is it different from plain C ?

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  14. Are you sure you don't have it backward? by tmoertel · · Score: 5, Informative
    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.
  15. Lines it is! by phorm · · Score: 4, Insightful

    That about clinches it. A lot of people really look down upon those who use any coding language that in any way simplifies the coding. The way I've always seen it is thus:

    Visual Basic is a very nice language for coding GUI-based applications. Newer versions have increased speed and performance such that there's not really a difference (exempting the included DLL's) between a standard office-type app made in VB and one in C++. If you want to get complicated and rip into the windows API, then you're probably doing something that may require C++, but VB often even handles this nicely. It interfaces much more nicely with the C-based DLL's than it used to in the past.

    My biggest peeve is the syntactical differences in compative operators and math. There was a time when I love VB, but now I truly hate having to do a "myvar = myvar+1", or the fact that you can't do something like "var1=var2+var3" (in VB that would give a boolean).

    In arguement for VC++, the wizards can handle a lot of the windowing/GUI stuff for you. I think that if if gave you some nice understandable error messages when you screwed up things might be a lot nicer. (it sucks when you get an ambiguous error message on line 2023 caused by a mistake on line 101).

    Since I've learned C++, I prefer it when possible. I have no huge qualms about writing a GUI in VB, or even a hybrid project with C++ DLL's linked to my VB GUI's. Every coder has their place. Just because one can program C and Fortran doesn't make them any better than a VB programmer. In a timed-trial for a small GUI app, the VB programmer would likely stomp the C progammer.

    If only MS could program better error messages... Error on line 342: unknown thingamabobber executing blingconfangler - phorm

  16. Well, solaris is written in C++ by autopr0n · · Score: 3, Funny

    but besides that, the core of the OS dosn't need to be very big, so you really can check everything.

    A huge program in C++ will probably have tons of buffer overflows to exploit. A Large Java program will have ZERO overflows.

    It's like comparing a hand grenade to an orange. Both can be handled safely, but an orange is just not going to blow up, no matter what you do, while the hand grenade has an increasing chance of exploding the more you fiddle with it.

    --
    autopr0n is like, down and stuff.
  17. Re:Language doesn't matter, language CLASS matters by jovlinger · · Score: 3, Interesting

    actually an old colleague of mine had the opinion that functional languages weren't _inherently_ more productive, but _did_ tend to attract programmers who understood abstraction at a deep level.

    these guys can write good code in _any_ language (he was a scheme hacker who was busy optimising HAIRY C gc code), but are attracted to functional langs because such langs directly capture the abstractions these guys use.

    so, to paint with a broad brush, functional languages aren't nec. better than imperative, but the functional paradigm (abstraction, genericity, focussing on data rather than process) IS.

  18. "Functional programming wins again" by ari_j · · Score: 5, Funny

    ...functional programming wins again...

    Of course it does, you idiot. ICFP stands for International Conference on Functional Programming

  19. Re:which functional language to learn? by jtdubs · · Score: 3, Interesting

    Functional programming eh?

    I'd suggest the following three languages:

    1. SML

    SML is the language on which OCaml is based. OCaml is really just SML with different (read: worse) syntax, some small differences, and then OO support.

    SML will probably be easier to start off on, is better supported and better documented.

    Once you've got SML down, OCaml will be easy.

    SML is strongly-typed, via type-inference.

    2. Common Lisp

    This is probably the most powerful language in existance.

    Functional if you want. Side-effects if you want. Based on mathematical theory. Closure of data and code. With CLOS (builtin) you get an incredibly powerful OO system.

    Common Lisp is dynamically typed and CLOS supports dynamic multiple-dispatch for typing.

    Lisp's defmacro system will open your eyes to a whole new world. It is the most powerful macro system you'll ever use. You can perform arbitrary transformations to your code. You'll never think the same way again once you've gotten the hang of defmacro.

    3. Haskell

    A very simple language to pick up the basics of. Pure functional. Lazy evaluation.

    A different idea than SML or Lisp.

    I think those three languages would expose you to pretty much all of the concepts of functional programming as well as all the different kinds of syntax you are likely to run across in functional languages.

    If you have some time to read up on lambda calculus it might be worth it.

    I also strongly recomment both of Paul Graham's Lisp books.

    Good luck,

    Justin Dubs

  20. Solomon by Effugas · · Score: 3, Insightful

    So, two parents divorce, and each gets half.

    Problem is, they've only got one kid.

    How much does each parent get?

    The story of Solomon points out that there are indeed discrete, indivisible quantities in this world that humans deal with on a regular basis. Though physically, the "type conversion" of the child into two bloody halves is possible, it's not likely what any programmer or parent wants.

    All sorts of other discretes exist for programmers. How many packets can I send, given one hour? 4/10th's of a packet is not a packet sent. How many widgets can be produced? A widget almost produced can't be sold. And so on. There is reality other than floats, good sir.

    --Dan

  21. Re:which functional language to learn? by e+aubin · · Score: 3, Informative

    SML is the language on which OCaml is based. OCaml is really just SML with different (read: worse) syntax, some small differences, and then OO support.


    From the Caml Faq

    The main reason is historical: Caml was invented before SML.

    The Caml language is issued from the original ML language, invented by Robin Milner in 1978, and developped jointly at INRIA from 1981. The first Caml compiler was written in 1984, and distributed from 1985. Standard ML was not yet invented, and Caml's syntax was similar to the syntax of ML V6.2, whose compiler was used to compile the first Caml compiler. When the syntax of Standard ML has been defined, Caml kept its own syntax, for several reasons. The first reason is questionable and subjective: we thought that SML's syntax was not a major improvement of the original ML syntax (hence of Caml's one). The second, more fundamental, reason is that we thought the language not to be mature enough at that time to be completely defined and fixed by a standard; we are still doing some progress on the understanding of some features of ML, and these progress may imply some important modifications of the language (let's cite the type checking of imperative features or the semantics and type checking of modules). In addition, we wanted to be free to add some new constructs (and indeed we did it, e.g. ``for''loops, ``try with'' and ``match with'', character constants, access to vectors and strings, ``mutable'' annotations for records, ``when'' clauses in pattern matching). This relative freedom with respect to the syntax allows the emergence of new variants of Caml: for instance the Caml Light and Objective Caml systems have their own extensions to the core syntax of Caml.

    Hence Caml has its own syntax.

    More interestingly caml has a pre-processor(camlp4)which allows to write in various other syntaxes. E.g. there is a Standard ML syntax, as well as a lisp-ish syntax.

    SML will probably be easier to start off on, is better supported and better documented.


    They both have nice documentation. They are so similiar I doubt it makes a lot of difference. The nicest new programmer ocaml documentation is The Oreilly Book Developing Applications with Objective Caml. With the exception of Ocaml's object oriented features, most ocaml documentation can be used w/ SML, and vise versa.

    Lisp's defmacro system will open your eyes to a whole new world. It is the most powerful macro system you'll ever use. You can perform arbitrary transformations to your code. You'll never think the same way again once you've gotten the hang of defmacro.


    For whatever its worth, camlp4 gives you a nice macro system too. I don't know how it compares w/ common lisps, but it does give you static checking of your macros and let you work at the abstract syntax tree level.

  22. Re:Language doesn't matter, language CLASS matters by alienmole · · Score: 3, Insightful
    Most of the well-known functional languages don't do lazy evaluation, so that would only be a "big ticket item" for languages like Haskell, which do.

    And no, I don't think your description captured functional languages very well - as you say, it sounded more like Prolog. Besides, the "rule-based" appearance of some functional languages (notably Haskell & the ML family) is really mostly syntactic sugar. Scheme, which is much closer to the pure lambda calculus on which most functional languages are based, doesn't have such a rule-based appearance.