Slashdot Mirror


ICFP 2003 Programming Contest Results

An anonymous reader writes "The previously reported ICFP Contest has been over for quite some time. The results were announced on August 26, 2003 at the conference in Uppsala, Sweden, yet the contest organizers have yet to publish results. Despite the forgetfulness of the organizers, it is known that this year C++ did well, taking first and second, but not judge's prize. Interestingly, a one-man team consisting of an undergraduate student took first place, followed by a team of highly ranked 'red' TopCoders, with the maintainers of Gwydion Dylan taking judge's prize."

101 comments

  1. Hey Americans: get a load of the truth! by Anonymous Coward · · Score: -1, Offtopic
    HOWTO: Be an American
    Version 1.0 / M

    America, eh folks? It's a pretty screwed up place. Unfortunately, but not indefinitely, the USA's weapons of mass destruction make it the most powerful country in the world (militarily). As a result, it helps to be aware of American society and fit into it, and our quick 8-step guide should have you on the path to burger-munching enlightenment.

    1 - Buy yourself a gun
    To become a fully-fledged Yank, you'll need to get a weapon. Americans think that having more killing machines magically makes their country safer, and it helps them to walk around saying "I'll put a cap in your ass". Even though the concept of "no guns = no gun-related crimes" is alien to the average Yank, it'll give you a false sense of security in this country with the highest crime rates in the developed world.

    2 - Put on at least 25 stone
    Skinny? Medium? Chubby? That won't cut it in the good ol' US of A. Because America has the highest obesty levels on the planet, you'll need to get those rolls of flab built up. Eating 18 waffles with Maple syrup for breakfast (and visiting Burger King five times in a day) is all natural when much of the world is suffering massive poverty. Get fat and fit in.

    3 - Learn the lingo
    We've talked about issues affecting society, but on a personal level you'll need more knowledge (or ignorance as it may be) to fit in. First, forget proper English. Confuse "your" with "you're". Say "must of" instead of "must have". Whenever anything interesting occurs, say "shucks" repeatedly. Instead of clever spontaneity or witty insults, call people "asswipes". It's funny!

    4 - Throw away all maps, history books etc.
    To really feel a part of American society, you must lose all knowledge of the world. Forget where Poland is. Scrap your knowledge of the lengthy Chinese history. Make cretinous remarks like "India? Is that in Africa?". Because ALL that matters is America, and it doesn't matter how pathetic you look to educated people the world over.

    5 - Become totally irrational and nonsensical
    Spout on about the Constitution, and then make drastic changes to it. Talk about "freedom of speech" and watch TV programmes about the Ku Klux Klan. Rant on about market freedom, and sit back as companies run riot and destroy the economy with their anti-competitive practices. Essentially, act idiotic at all times.

    6 - Sue everyone you ever meet
    The USA doesn't produce many decent quality products, so the society is crumbling into a litigation-happy joke. With so many jobs going overseas to talented workers, your only option left is to start legal proceedings. About anything. Someone step on your toe? Get some hotshot downtown lawyer to sue their ass!

    7 - Get a "shrink"
    Americans have a hard time dealing with their own problems in a mature manner, and prefer to spend hundreds of dollars sitting in front of someone and whinging. However trivial your problems may be, blast them out like a baby!

    8 - Watch abysmal TV
    Forget educational programmes and incisive documentaries. Your ideal night in is with your gun, six cheeseburgers and a Friends box set. Watch as some over-paid talentless "actor" enters the scene, and whoop and scream hysterically as he delivers some ridiculously poor wisecrack.

    So there you have it! Those 8 steps should have you killing innocent people, piling on pounds and acting like a moron in no time. America awaits you, brave hero! Just get out before it collapses in disarray.

    END

    1. Re:Hey Americans: get a load of the truth! by Anonymous Coward · · Score: 0

      Wasn't Friends based on a British comedy series? You know what's really funny? Baywatch was a flop here, and only the fact it was popular internationally saved it.

    2. Re:Hey Americans: get a load of the truth! by Anonymous Coward · · Score: 0

      no way...maybe you're the gay fuck who didn't like baywatch. real americans loved hot babes on baywatch. i watched it everytime it was on...

      wait...that could have been because i was 12 back then. but, whatever.

    3. Re:Hey Americans: get a load of the truth! by Anonymous Coward · · Score: 0

      Did you miss the time NBC cancelled it due to low ratings? They had to revamp the show, and shop it around in Europe before it made it back to syndication.

    4. Re:Hey Americans: get a load of the truth! by perly-king-69 · · Score: 1

      No it wasn't. British comedies are funny.

      --

      --
      This sig is inoffensive.

    5. Re:Hey Americans: get a load of the truth! by Anonymous Coward · · Score: 0

      You must not have watched "Are You Being Served?"

    6. Re:Hey Americans: get a load of the truth! by Anonymous Coward · · Score: 0

      Two words: Benny Hill

  2. MICHAEL SIMS IS A GAY CENSOR MONKEY! FP! by Anonymous Coward · · Score: -1, Flamebait
    1. Re:MICHAEL SIMS IS A GAY CENSOR MONKEY! FP! by Anonymous Coward · · Score: -1, Offtopic

      YOU FAIL IT.

    2. Re:MICHAEL SIMS IS A GAY CENSOR MONKEY! FP! by Anonymous Coward · · Score: -1, Offtopic

      No. I got the true fp. As you can clearly see, the imposter fp failed it, and it was promptly pointed out. So suck my dick, asshole.

  3. Yep... by Anonymous Coward · · Score: -1, Offtopic

    Just like on Yahoo!

  4. Prolog by Anonymous Coward · · Score: -1, Offtopic

    HOw come prolog didn't win? it is
    quite hard to read.

  5. huh! by The+Clockwork+Troll · · Score: -1, Troll
    I did not know Juggalos could code.

    That almost redeems the face-painting and assorted other developmental disabilities.

    --

    There are no karma whores, only moderation johns
  6. my piss by Anonymous Coward · · Score: -1, Offtopic

    is frostier than shafts

  7. WHO CARES by Anonymous Coward · · Score: -1
    seriously.

    anybody?

  8. YOU FAIL IT! by Anonymous Coward · · Score: -1, Troll

    Hey, fuck you. Your fp has been claimed by me. You therefore fail it, asshole. So get busy sucking my dick. And so you know, I'm from Germany. I'm not an American. Fuck you.

  9. Of course by Anonymous Coward · · Score: -1, Troll

    C++ is an excellent language.

    It is rather amusing to see the functional programming zealots beaten in their own competiition.

    Now maybe the FP "movement" will go back to relative obscurity where it belongs, and let the real programmers do their jobs.

    1. Re:Of course by be-fan · · Score: 3, Insightful

      That's not entirely fair. There are lots of places where functional programming is the way to go. You'd be surprised at how much stuff you "real programmers" come up with that the FP world did better, more cleanly, and years ago. XML and XSLT come to mind, as well as some of the weirdness they've begotten.

      Its really a matter of what kind of programming you are doing. FP is all about making algorithms primary and data secondary. There are some applications where this fits. Take, for example, parsers. In writing a parser, you've only got to deal with a few tokens at a time. Try writing a Scheme parser in imperative vs functional style and tell me which one is shorter and cleaner. However, in some applications, data is the only important thing. Take, for example, an OS kernel. In a kernel, most work boils down to finding highly efficient data structures to track certain state, and writing highly efficient algorithms that mutate that state. Functional programming isn't a good fit for this --- its is often very difficult to express algorithms in a pure-functional manner that have the same asymptotic complexity as their imperitive counterparts.

      --
      A deep unwavering belief is a sure sign you're missing something...
    2. Re:Of course by angel'o'sphere · · Score: 4, Informative

      Your comparision is not quite correct.
      FP is all about making algorithms primary and data secondary.
      In FP, functions *ARE* data. The main way to distinguish programming languages, or programming paradigms, is by looking at the question: what are the so called "first class citicens?" (fcc)

      In "procedureal" languages the fcc's are *NOT* "procedures", its only called procedural because the main "structuring" feature at that time was the procedure.
      Functional languages are best set in relation to oo languages (or oo-like languages like Java and hybrids like C++). The most heavyly used fcc's in oo languages are objects. Thats what you create and what you pass around. E.G.: you create an object and pass it via a call to an algorithm.
      In functional languages, the things you create are: functions, not objects, not structs. the things you pass around are functions, you *apply* a funcion on some data.
      In both cases you still have data, and still you have algorithms.
      What makes fuctional languages "inefficient" in some respects is the fact that they in general do not manipulate "state" of some data, but consider data to be read-only and yield an result instead. Suppose the whole kernal memory is the state of a system, a functional "kernal" would compute a complete new kernal state as a value object.
      OTOH: functional languages are inherently multi threaded, as they only read access unchangeable data.
      Regarding your - hypotetical - question wether a scheme parser written in scheme would be easyer than a standard C/Pascal parser ... who knows? Scheme is that easy to parse, that the questin makes no real sense to me. It only looks more beautyfull if you find scheme beautyfull ... wich I don't :-)
      BTW: its is often very difficult to express algorithms in a pure-functional manner that have the same asymptotic complexity as their imperitive counterparts
      This makes no sense to me, either. The asymptotic complexity of a problem has no relation to the programming paradigm you use -- only to your skills in that paradigm.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    3. Re:Of course by Anonymous Coward · · Score: 0

      Learn to spell. Christ.

    4. Re:Of course by be-fan · · Score: 2, Insightful

      In FP, functions *ARE* data.
      >>>>>>
      "State" probably would be a better word to use here. A procedural language is all about state. You call a procedure, and it modifies some state. If you want to reason about the program, you have to reason about all the state. In a functional program (rather than an imperative program written in a functional language) function application is primary, and state only exists in function parameters and return values. This minimizes the amount of state one has to think about at any one time.

      In both cases you still have data, and still you have algorithms.
      >>>>>>>
      You do, but the relative importance of each is different. The whole idea of OO is that you have objects --- which are containers of state. You have some methods that imperitively modify that state. The central paradigm is the manipulation of state. In function programming, state is secondary to functions. You call a function that evaluates something, and state is only relavent to the functions that receive them as parameters, and return them as results.

      What makes fuctional languages "inefficient" in some respects is the fact that they in general do not manipulate "state" of some data, but consider data to be read-only and yield an result instead.
      >>>>
      Precisely.

      Suppose the whole kernal memory is the state of a system, a functional "kernal" would compute a complete new kernal state as a value object.
      >>>>>>>>>
      Yep. Now the key thing here is that this makes sense in lots of cases. Take this ICFP contest. The idea is to compute the most optimal path through a track. The only thing that matters is the result. FP makes sense here. In comparison, a kernel is all about state. There is no result to compute, and functions are only useful in that they allow manipulation of state. FP makes much less sense in this area.

      Regarding your - hypotetical - question wether a scheme parser written in scheme would be easyer than a standard C/Pascal parser ... who knows?
      >>>>>>
      I think you misunderstand me. Both languages are writing a parser for Scheme. I choose Scheme because its a traditional introduction to writing parsers. Compare writing a parser for Scheme in an imperitive style (in any language) vs writing it in a functional style (for any language). The functional approach is much more clear.

      The asymptotic complexity of a problem has no relation to the programming paradigm you use -- only to your skills in that paradigm.
      >>>>>>>>>>>
      Actually, they do. If you're writing in a purely functional language (Haskell/ Clean) you can't use side-effects. As a result, straightforward implementations of many traditional algorithms become more complex. For example, getting purely functional graph algorithms that are as efficient as traditional imperitive algorithms is an important focus of research in functional programming circles. Now, if you're writing a program where state is just a necessary evil, you can get away with using complex methods (monads, language features like uniqueness types) to deal with that state. If your program is *all* about state (like in a kernel) its probably better to write it in an imperitive style.

      --
      A deep unwavering belief is a sure sign you're missing something...
    5. Re:Of course by mvw · · Score: 3, Insightful
      C++ is an excellent language.

      Yes, it is. It allows you to both program close to the hardware and on an abstract level. The focus is on efficiency.

      But sometimes you want other goals first. In case of concurrent and fault tolerant programming I would rather use Erlang. For GUIs you can hack it together quicker if you rely on Java and its excellent development tools.

      It is rather amusing to see the functional programming zealots beaten in their own competiition.

      I don't mind. What I mind is that organizer did not officially publish the results. I sent several emails. No reaction. :(

      Perhaps the problem posers got tared and feathered after the conference for posing a problem that was more suited to imperative programming. :-)

      Now maybe the FP "movement" will go back to relative obscurity where it belongs, and let the real programmers do their jobs.

      I hope you mean the F1rst P0st crowd, otherwise I have to consider you being an ignorant idiot.

      Regards,
      Marc

  10. Godspeed, Andrew Hudson by stevesliva · · Score: 5, Interesting

    I wonder how many job offers 1st place winner and UT undergrad Andrew Hudson is going to receive... or for you conspiracy folks out there, how many shadowy organizations he'll be "invited" to join.

    --
    Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
    1. Re:Godspeed, Andrew Hudson by Anonymous Coward · · Score: 0

      Unreal Tournament? They're offering degrees for UT? Damn. I wish I went to his school.

  11. Awesome by be-fan · · Score: 5, Interesting

    Its nice to see my two favorite languages take the top spots :) Its also pretty nifty that the Gwydion Dylan team got another prize. They got second place a couple of years ago too. Anyway, more people need to check out Dylan. Its a pretty nifty language. It was made by Apple in the early 1990's, by a committe containing a lot of important Lisp people. As a result, its kind of an object-oriented Lisp with a more traditional syntax. Its a very powerful language, but also very fast. It was designed to achieve 90% the performance of C. In practice, the current Gwydion compiler (designed by the same group at CMU that did CMUCL) achieves 50-90% given similar code.

    --
    A deep unwavering belief is a sure sign you're missing something...
    1. Re:Awesome by Anonymous Coward · · Score: 2, Insightful

      But the uniformity of the syntax of lisp (actually VERY traditional, going back to 1958...) is one of its major advantages.

      Dylan, a bit like Python, is a "gateway" language. People start using it, and slowly come to realise what makes lisp great. Then they make the leap to Lisp. Handy :-)

    2. Re:Awesome by be-fan · · Score: 3, Interesting

      Dylan has some nice features that I didn't find in Common Lisp. Like Smalltalk, Dylan is objects "all the way down." Its also got some nice performance features like limited types and sealing. Overall, its just more elegant because it doesn't have the baggage of evolution and a standardization committe. This makes little difference in practices --- its mostly conceptual cleanliness. But Dylan is my hobby programming language (I do C++ at work) so I get to be arbitrary and choose elegance over practicality. That said, from my experience with Scheme, I have to say the prefix syntax is growing on me, and I'd love to see a resurrection of prefix-Dylan.

      --
      A deep unwavering belief is a sure sign you're missing something...
    3. Re:Awesome by rplacd · · Score: 0
      But the uniformity of the syntax of lisp (actually VERY traditional, going back to 1958...) is one of its major advantages.

      I agree that Lisp's syntax makes many things easy -- stuff that can't be done as elegantly in other languages -- but it's not that old. Google for "M-Expressions"; example links: here and here.

    4. Re:Awesome by andreas · · Score: 2, Insightful

      There are two advantages with the Lisp syntax: it is easy to write parsers for, and is easy to write powerful macros that make the syntax extensible.

      Now we don't have 1958 anymore, and writing parsers for high-level languages is no black art anymore. A proper syntax makes code easier to read and to maintain, and laziness on the side of the compiler writer cannot be held up as an argument to make usage of the language harder to the user.

      And Dylan introduces a macro system that works much like the Lisp macros used to, only with an Algol-like syntax. Basically, the macros work on the parse tree instead of the string representation, and thus can be used to extend the syntax of the language, If you want, you can think about it as adding productions to the grammar.

      Dylan definitely is a dialect of Lisp, with another syntax. And it has been cleaned up in a lot of places, too (OO from the ground up, for instance).

    5. Re:Awesome by Anonymous Coward · · Score: 2, Interesting

      Technically, Common Lisp is objects all the way down, too, actually. The confusing thing is that methods are specialised on types, not objects, and builtin methods can't always be truly extended or overridden (though you can create identically named methods in different packages). Check out recent thread "Everything is an Object" on comp.lang.lisp.

    6. Re:Awesome by be-fan · · Score: 1

      That's the bit that bothers me, that built-in methods can't always overridden. Like I said, this is largely a conceptual problem I have with CL, not a practical one.

      --
      A deep unwavering belief is a sure sign you're missing something...
    7. Re:Awesome by Anonymous Coward · · Score: 0

      Uh. Lisp syntax is a proper syntax. It's just about the clearest there is (except maybe Forth). I personally like lisp syntax because it's so simple. I always end up fully parenthesising infix syntax because, while any one language might be "easy" from the perspecitve of the language designer, the different infix languages make different precedence choices, and it's much easier to remember to fully parenthesise than to learn the stupid differences between C and SQL or whatever.

      Lisp's clear, unambiguous, uniform syntax means that I can guarantee the ability as a HUMAN to understand OTHER PEOPLE'S programs, without wondering whether the other programmer was aware of the precedence rules of a particular language, and really meant what he wrote, or whether the fact he took the modulus before multiplication was unintentional.

    8. Re:Awesome by timeOday · · Score: 1

      Lisp syntax is TOO simple, just not expressive enough. When 2x^2+3x-4 becomes (- (+ (sq (* 2 x))) (* 3 x)) 4) then something is wrong. I prefer the extra complication of operator precedence; learned once, it simplifies the code forever... just like many of the other syntactic quirks of other languages. And no static type checking? And although the syntax is very simple, can we say the same for Common Lisp as a whole? If people didn't want/need some complexity, Lisp would be Scheme.

    9. Re:Awesome by Anonymous Coward · · Score: 0

      But you can't learn operator precedence just once, unless you only learn one language. Different languages have subtly or blatantly different rules.

    10. Re:Awesome by Raffaello · · Score: 1

      Since common lisp is already a *strongly typed* language, type checking is easy. You can have whatever level of type checking you want - you just have to code accordingly.

      Since common lisp is a *dynamic* language, you can't have static type checking. Indeed, static type checking is only a meaningful concept when it is possible for the compiler to know the type of every program entity at compile time.

      The desire for static type checking betrays a false understaning of the nature of programming - i.e., the implicit belief that all programs are fixed algorithms operating on data, the type of which is known at compile time, in order to produce output, the range of which is well understood at compile time.

      Many more straightforward progamming tasks do still take this form. It is, however, extremely short sighted to believe that this limited (and fairly trivial) set of tasks should form the basis for the specification of all general purpose programming languages.

      Most of the more interesting things that can be done in software require that the program deal gracefully with input data types that were not fully known at compile time (because of inheritance hierarchies and object interactions), yielding outputs that may not have been anticpated at all (because interesting programming means exploration of new areas, not reinventing the wheel).

      To impose static type checking on programmers is to virtually guarantee that they will merely reinvent known solutions to known problems ad infinitum, just because their language tools don't allow them to deal with the new and unexpected gracefully.

    11. Re:Awesome by Anonymous Coward · · Score: 0

      Uh? So why does Common Lisp have optional static typing. CMUCL is even a type-inferencing compiler, often it produces much better compiled binaries if you give it a few key type declarations.

    12. Re:Awesome by Haeleth · · Score: 1

      As you admit, most tasks in programming _do_ operate on predictable data; the main area in which an algorithm wants to handle unpredictable data is surely the construction of generic libraries, for which purpose static, but polymorphic, typing, as in Haskell or ML, or to a lesser extent C++ templates, does a pretty good job. The earlier AC reply to your post mentions a type-inferring version of Common Lisp - type inference being a mechanism which provides the security (and speed!) of static typing with nearly all the simplicity and extensibility of dynamic typing.

      To bring this back on topic, it's worth noticing that the ICFP programming contest has never been won by a dynamically-typed language...

    13. Re:Awesome by brucehoult · · Score: 1

      To bring this back on topic, it's worth noticing that the ICFP programming contest has never been won by a dynamically-typed language...

      That's true and I think very interesting, as I pointed out in my 2001 writeup.

      Of course what I didn't know when I wrote that was that our dynamically-typed language (Dylan) ended up in 2nd place that year (and with the Judges' Prize this year).

      Also, a team using Erlang won the Lightning Prize in 2001, and a programmer using Python won the Lightning Prize in 2002.

  12. Useful programming challenges by JusTyler · · Score: 5, Interesting

    Congratulations! I've usually steered clear of checking out programming "challenges" because they usually seem to be focused on producing the most unreadable or obscure code to confuse the judges.

    While you can learn things from obfuscated code, I think these practical challenges are a lot better for the programming community as a whole.

    Finding optimal paths around race tracks and obstacles presents a number of challenges which when solved in multiple totally different ways, helps give us new theories and data which we can use to develop new algorithms and theories for use in the real world.

    Can anyone recommend any other programming challenges which focus on developing new algorithms which may be useful in other disciplines?

    The only example I can think of is the many "robot" fighting challenges, where you write a program for a robot, and it has to destroy the other robots within the battlefield using its own "wits" and no human input. You might remember PC-ROBOTS from the early 90's if you're a real geek ^v^

    1. Re:Useful programming challenges by register_ax · · Score: 2, Informative
      Can anyone recommend any other programming challenges which focus on developing new algorithms which may be useful in other disciplines?

      The only example I can think of is the many "robot" fighting challenges, where you write a program for a robot, and it has to destroy the other robots within the battlefield using its own "wits" and no human input. You might remember PC-ROBOTS from the early 90's if you're a real geek ^v^

      It sounds like you are making reference to robocode, but it's hard to tell since you mention PCRobots. If you weren't, well then you might want to check it out.

  13. your piss by Anonymous Coward · · Score: -1, Troll

    is lukewarm and staler than bigfoots, since YOU FAIL IT

  14. Not among the winners: *BSD by Anonymous Coward · · Score: -1, Offtopic
    Although it is true that BSD is dying, there are some helpful steps you can take ease your sorrow:
    • deal with the inevitable.
    • grieve for your loss.
    • move on. Never let your emotions get mixed up with something as silly as a computer operating system. It isn't healthy. So BSD fails. Big whoop. Deal with it and move on. Hope this helps.
  15. That's great by Anonymous Coward · · Score: 2, Funny

    That's great, but he used SCO code. And he coded all this while listening to illegal MP3's. SCO and the RIAA are filing a joint suit against his grandmother.

    1. Re:That's great by Doom+Ihl'+Varia · · Score: 1

      The blind grandmother or the one in the wheel chair?

    2. Re:That's great by kurosawdust · · Score: 3, Funny
      SCO and the RIAA are filing a joint suit against his grandmother.

      His twelve-year-old grandmother....

      You gotta give the story an extra "kick"

  16. Why? by Anonymous Coward · · Score: 0

    Based on the posts above, it seems like the FP movement is alive and well at slashdot.

  17. Non-functional programming languages by jfengel · · Score: 4, Interesting

    I guess it should come as no surprise that the winners should be programming in the decidedly non-functional (no pun intended, really) language C++. There are far more C++ programmers out there than Dylan, Haskell, and ML combined, probably by a couple orders of magnitude.

    The prizes were awarded based on answer quality, not performance, which takes away one of C++'s natural advantages over functional languages. Still, I'd like to see a breakdown of entry languages.

    1. Re:Non-functional programming languages by Haeleth · · Score: 4, Insightful

      Funnily enough, I came away with the impression that C++ had an advantage this year, since the removal of the requirement that the judges run the program themselves meant, in theory, that a brute-force approach combined with a supercomputer could have beaten the most delicately honed algorithm imaginable. That the winner was not an example of this surprised me.

      Ah well. Those of us with functional inclinations can console ourselves with the knowledge that at least the winning program didn't use COBOL...

    2. Re:Non-functional programming languages by Ben+Escoto · · Score: 4, Interesting

      It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).

      In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list. In fact the entry list is interesting in itself to see all the languages people use.

      And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.

    3. Re:Non-functional programming languages by Anonymous Coward · · Score: 0

      > a brute-force approach combined with a supercomputer could have beaten the most delicately honed algorithm imaginable

      Not really, and it shouldn't have surprised you. A fast time around one of the race tracks was a few thousand moves. There were 7 choices that can be made at each move. It doesn't really matter if you had all the computers in the world cranking through the problem. 7^5000 states is not something that can be computed in this universe.

    4. Re:Non-functional programming languages by Anonymous Coward · · Score: 0
      Funnily enough, I came away with the impression that C++ had an advantage this year, since the removal of the requirement that the judges run the program themselves meant, in theory, that a brute-force approach combined with a supercomputer could have beaten the most delicately honed algorithm imaginable. That the winner was not an example of this surprised me.
      The winner used significantly more computing power than the runners-up. From the winner's web page "I chose to defend C++, and used 16 Dual XEON 1.8Ghz machines."
    5. Re:Non-functional programming languages by Anonymous Coward · · Score: 0

      Ya, anybody who knows a little QBasic and has 16 Dual XEON machines could have won this without even losing any sleep.

    6. Re:Non-functional programming languages by kruntiform · · Score: 1

      The competition was judged on performance in a way. The contestants had only so much time to prepare their entries, and much of that time must have been eaten up by their programs doing computation. The winning entry had an element of brute force computation together with a clever method to reduce the amount of computations. C++ sounds like a good choice for that approach.

    7. Re:Non-functional programming languages by gfim · · Score: 1

      The winner may have used files with a .cc extension and he may have used a few standard library constructs but it's a C program, not a C++ one.

      --
      Graham
  18. "Hudson... 5 penises = a good time" by Anonymous Coward · · Score: -1, Troll

    Thats strange, now isn't it!

  19. Hahaa. by E_elven · · Score: 0, Funny

    cout
    c++in

    --
    Marxist evolution is just N generations away!
  20. What does ICFP stand for? by Anonymous Coward · · Score: 0

    I have been looking around the ICFP web pages, looked at that previous Slashdot article, and even checked the FAQ on the ICFP homepage, and I still haven't found out what the ICFP acronym stands for... Anybody knows?

    1. Re:What does ICFP stand for? by mthreat · · Score: 0, Troll

      "I Can't Fucking Program"

    2. Re:What does ICFP stand for? by LoneIguana · · Score: 4, Informative

      from: http://developers.slashdot.org/comments.pl?sid=688 44&cid=6294481 [qoute] ICFP stands for International Conference on Functional Programming. Neither the /. story nor the contest website make this clear [/quote]

  21. iuh by Anonymous Coward · · Score: -1

    can someone please explain to me why gmx has been down?

  22. wondering by segment · · Score: 1


    I wonder (because I see no mention of it) how many different languages we used in the contest aside from the standards (C++, C, etc). Recently I've been playing with Ruby which is pretty handy at times, and I swear by python, and expect. Well coming from a sysadmin background I swear by these... Anyone know if languages like these were entered or,, even if others use python and expect on a normal basis, hell even ruby for that matter.

    1. Re:wondering by Ben+Escoto · · Score: 1

      Yes, previous years have featured Python and Ruby contestants. I believe one year Python won the judge's award, but IIRC neither language has come in first or second.

      I think the problem with Python and Ruby are that they are both about 10+ times slower than Ocaml/C++ (to name two lanuages that often do well in the contest) and often running time is heavily weighted in the scoring.

    2. Re:wondering by Anonymous Coward · · Score: 0

      I agree that this is a problem. Lack of speed often results in hacks, or rewriting code in a faster language.

      The speed of python is changing though. Not just with the main CPython which got about 30% faster last release. With the psyco specializing compiler I can get close to the speed of c, or faster in a few cases. It still has a way to go, but allready speeds up a lot of stuff. Also psyco is cross platform now :)

      Of course the top speed is in runtime assemblers. Hrmm... which is what psyco uses under the covers.

  23. 'red' TopCoders by frovingslosh · · Score: 1

    What the hell does 'red' TopCoders mean? They were red-heads? They were Russian? They programmed all night and needed Visene to clear up their eyes?

    --
    I'm an American. I love this country and the freedoms that we used to have.
    1. Re:'red' TopCoders by Anonymous Coward · · Score: 0

      Yeah, I always thought TopCoder was not really]][[ compatible with Communist ideals, but hey, it's the year 2003... where else is a Red coder to go?

    2. Re:'red' TopCoders by jaxdahl · · Score: 2, Informative

      Take a look at the topcoder.com site. It's a periodic competition with short round matches that take a little over an hour to complete 3 challenges. These challenges are similiar to ACM competitions, but quite a bit easier b/c of the time limitations. The rankings are given in points kind of like chess, and the highest ranked coders are color-coded red. Below that is yellow and so on. Thus the best coders are 'Red coders'.

    3. Re:'red' TopCoders by lars · · Score: 4, Informative
      TopCoder is a company that recruits programmers, sells software components, runs high school contests, etc. (They probably do other things now too.) One of the main ideas behind the company is to rate programmers as objectively as they can. This acknowledges the fact that experience or specific skills on a resume don't necessarily provide a good indication of the programmer's true ability and productivity. The main way TC evaluates coders is based on programming competitions and component design and development competitions.

      I've been participating in TC's programming contests for more than a year. There are weekly contests, each of which take only about 90 minutes of your time. There are no prizes given out for the regular contests any more, but I really enjoy being able to get a nice mental workout, and compare myself to some really elite programmers. Most of the top-ranked coders have done extremely well in other prestigious international math and programming contests. And even if you aren't at the level of the top ranked guys (mostly - I think the highest ranked woman is around 50th or so, it would be nice to see more female participation), it can still be fun to work on improving your rating and other statistics such as submission accuracy. The rating system is modelled after the FIDE system for rating chess players.

      There are many other reasons to participate. You can also learn a lot by looking at the submissions by the top ranked coders. If you're looking for a job and do reasonably well, there's a good chance one of the many sponsor companies will be interested in hiring you. And perhaps most of all, TC has two big tournaments each year - the open, and the college invitational. These tournaments usually have a total prize purse of $100,000 or more, and pay out $50,000 or more to the winner.

      Finally, to answer your question; the TC ratings brackets are split up into different colours. 'Red' is the highest bracket, and includes anyone with a rating higher than 2199. This corresponds to roughly the top 2% of all rated members.

    4. Re:'red' TopCoders by Anonymous Coward · · Score: 0

      Rank Name # Rated Avg. Rating 1 Sweden 17 1559.35 2 Germany 22 1395.63 3 Poland 14 1370.64 4 Norway 14 1357.28 5 China 59 1333.47 6 Ukraine 12 1332.58 7 Russian Federation 13 1264.69 8 Australia 28 1123.35 9 Canada 134 1121.67 10 United Kingdom 24 1053.00 11 United States 1275 1028.67 12 Romania 18 1024.00 13 Brazil 14 1006.92 14 India 43 903.93

    5. Re:'red' TopCoders by Anonymous Coward · · Score: -1, Offtopic
      Sounds like its attractive to faggots who can't see much past their computer and end up taking it up the ass from their devo workmates just because any woman riuns screaming from them....

      .Ahhhh, is that you ???

    6. Re:'red' TopCoders by Anonymous Coward · · Score: 0

      nope, i'm the devo workmate (pun intended?)

  24. Programming Lover by Cory+Doctorow · · Score: -1, Troll

    I just love programming and whenever it's mentioned it just makes my day guys!!! Programming and programmers are cutesies! Toodles! :0) :) omg ;)

    --
    come to my blog at http://www.boingboing.com Love ya!
  25. Where's Andrew Hudson's C++ contest entry? by Anonymous Coward · · Score: 0

    I see that most other entries have posted their code to download. Where's his?

    1. Re:Where's Andrew Hudson's C++ contest entry? by }{@wkmooN · · Score: 1

      Right there on the page
      but for the lazy: http://www.cs.utexas.edu/users/ahudson/submit-huds on.tgz

  26. Simple plan by KyleW · · Score: -1, Offtopic

    Hehehe I just joined TopCoder and I'm gonna make fat $$$. 1) Join TopCoder 2) ??? 3) Profit!

    --
    1st known failed CIA coup in South America : http://www.chavezthefilm.com/index_ex.htm
  27. Access to fast machines required? by Ben+Escoto · · Score: 4, Informative

    This contest concerned virtual racing tracks. The winner was the one who submitted the trace which would pilot the car as fast as possible around the track. (See the problem description for more information.)

    Thus the judges never ran the program on their computers, and in theory could have judged the contest without even looking at source code. To me this seems a bit unfair because the winner could just be the one with the fastest computer, not the best code. I noticed that the first prize team used 16 dual Xeons.

    So did anyone here compete? In practice are the results greatly influenced by how much hardware the contestants had access to?

    1. Re:Access to fast machines required? by Bob+of+Dole · · Score: 3, Informative

      The "speed" was in simulation ticks, not elapsed time.
      So on a 486 or a 16x-Xeon, 3000 ticks is 3000 ticks, doesn't matter how long it took to simulate in real time.

    2. Re:Access to fast machines required? by ratpack91 · · Score: 1

      well they were the person who won completed all the tracks in the shortest total steps, where 1 step is one unit of time. They did not get judge on the amount of cpu clocks cycles it took so yes having a faster machine would definitely help as stated in the rules pdf. A 486 might have taken a week or longer to achieve the same result using the same algorythm

    3. Re:Access to fast machines required? by Anonymous Coward · · Score: 0

      you are a retard.

    4. Re:Access to fast machines required? by Anonymous Coward · · Score: 1, Informative

      Actually, it was never intended to become a raw computational task.

      The "idea" that we organizers thought would be the winning one was computer assisted manual driving, and that the task would become writing a GUI for that purpose. Which would have been pretty much CPU-power independent.

    5. Re:Access to fast machines required? by kent.dickey · · Score: 2, Interesting

      I entered using a fairly average machine (Apple powerbook G4). It looks like I came in 30th out of about 90 entries (I'm "apple2gs"). I'm disappointed that I had to find out results through slashdot.

      My strategy was to try to use "waypoints" to help guide an optimizing algorithm, but I gave up and just made a manual car simulator (meaning, you manually enter the commands, and my program just shows where the car is and if it's hit a wall yet). With more time, I could easily improve most tracks by at least 5% by just racing them through again. This would only move my rank by a few places, though.

      So machine speed was not that big a factor in my case. Others also made simple driving simulators as well, although I don't know how well they did overall.

    6. Re:Access to fast machines required? by nothings · · Score: 2, Interesting
      Access to fast machines probably made a big difference in the results, and this was a major change from past ICFP competitions (which were run by the judges under fixed time constraints).

      The winner noted:

      I used 17 Dual P4 1800Mhz computers. (Without the permission of the CS Dept... sorry guys no time to get permission..)
      (here)

      He also probably wrote the least amount of code of anyone. (A link to his source is posted in the same forum.)

      To be fair, he also took an approach that my team wrote off as unachievable when it obviously wasn't unachievable--brute force search of the solution space. (Specfically, brute force search of the "whole" solution space reduced by restricting solutons to only change control settings on pixel crossings [and certain quantized speed changes].)

      Meanwhile my team's solver got beat by some people who just interactively solved the courses with a human driver. Embarassing.

    7. Re:Access to fast machines required? by mvw · · Score: 3, Interesting
      The "idea" that we organizers thought would be the winning one was computer assisted manual driving, and that the task would become writing a GUI for that purpose.

      I was aiming for manual assisted computer driving. Something like providing the control points and let the computer draw the Bezier spline.

      To brute force the general problem I wouldn't dare in the first place.

      I wasted most of the time reading and writing stuff between the various formats and to get my simulator implementation running exactly like the official one. Which was probably 1-2 days too much. Coming up with such an optimizing GUI would have taken another 2-3 days for me.So the winners did a good job.

      Regards,
      Marc

    8. Re:Access to fast machines required? by Anonymous Coward · · Score: 0
      He also probably wrote the least amount of code of anyone. (A link to his source is posted in the same forum.)
      The quantity of code has little bearing on the complexity or novelty of an algorithm.
  28. You know you are out of your depth... by eyeye · · Score: 2, Insightful

    when you dont even understand the problem.

    I read the dylan entry description and didnt even understand the problem. *smacks head*

    --
    Bush and Blair ate my sig!
  29. 2002 ICFP language breakdown by truth_revealed · · Score: 4, Informative

    Values taken from the ICFP 2002 webpage and munged with an awk script... not 100% accurate, but close enough.

    language entries

    java 28
    c 24
    c++ 22
    caml 19
    python 15
    perl 11
    scheme 7
    haskell 6
    lisp 5
    dylan 2
    erlang 2
    mercury 2
    pltbot 2
    ruby 2
    ada 1
    bot! 1
    dogs 1
    extensions 1
    forth 1
    icon 1
    kylix 1
    lspm 1
    mhotas 1
    pandemonium 1
    pps 1
    prolog 1
    sk 1
    smalltalk 1
    sml 1
    v202 1

    Some languages are bogus because of the format of the author's entry, or they used multiple languages.

    1. Re:2002 ICFP language breakdown by Anonymous Coward · · Score: 0
      Where's Object COBOL, dammit? What's up with punk kids these days? From what I've heard, it's quite a functional language.

    2. Re:2002 ICFP language breakdown by Anonymous Coward · · Score: 1, Interesting

      It's interesting to note that even though there were a lot of Java entries - more than any other language - they did not rank very highly. The sheer number of programmers for a given language does not necessarily lead to better solutions in that language.

    3. Re:2002 ICFP language breakdown by jfengel · · Score: 1

      I'm disappointed by the overall poor performance of Java. Another poster pointed out that there was limited time to bang out the program, and I personally consider Java to be faster to program in than C++, especially for larger programs.

      Perhaps the size of the task was small enough that C++'s memory difficulties don't occur. If your memory requirements are low enough that you don't need to free memory, you eliminate an important source of wild-goose-chasing that often occur in C++ programs. One crash caused by overzealous memory freeing can waste an infinitude of hours, as can tracking down the source of a memory leak.

      Or perhaps the programmers now have enough discipline to free memory always, and only, when it's required.

    4. Re:2002 ICFP language breakdown by Anonymous Coward · · Score: 0

      I'm sorry that your favorite language, Java, did not fair well. You'll find this hard to believe but most C++ programs are much shorter than their Java equivalents due to the intelligent application of templates. In fact, the winning C++ entry for the 2003 contest was just a couple of hundred lines long. Don't trust me - count the lines for yourself and compare it to the Java entries. Also, any experienced C++ programmer only rarely experiences the memory problems you talk about. Memory's more of an issue in Java where its garbage collector usually hangs on to 4 times as much memory as the equivalent C++ program.

    5. Re:2002 ICFP language breakdown by jfengel · · Score: 1

      This isn't really the place or time for the age-old language war to break out, so let me just say that I agree with you. A good C++ program, written by a smart C++ programmer, is usually a better program. I consider myself a smart C++ programmer, and I never had memory leaks or crashes in my code.

      However, I find that this industry is filled with people who aren't smart, good, diligent programmers, and I prefer Java for working with such people. Time that I don't spend working out crashes due to their memory management is a huge boost to my productivity. That's just my bias; I tend to work on large projects with many people, and I rarely get to pick my team to suit me.

    6. Re:2002 ICFP language breakdown by Anonymous Coward · · Score: 0

      However, I find that this industry is filled with people who aren't smart, good, diligent programmers, and I prefer Java for working with such people.

      Such bad programmers do not generally enter these contests. If a language does not rate highly there must be a reason. Either good programmers are not attracted to the language or the language is deficient in solving the problem easily in some way.

      You generally get the best examples of programming in each language for the ICFP contests.

      Yes, bad programmers can make quite a mess of C or C++. They should stick to a memory safe languages like Java. But I've never had a problem with C++ in large teams of capable programmers.

      A good C++ programmer is almost certainly better than a good Java programmer. Any C++ programmer can learn to be a great Java programmer, but the opposite is generally not true.

    7. Re:2002 ICFP language breakdown by gfim · · Score: 1

      Or perhaps they use smart pointers.

      --
      Graham
  30. ICFP stands for... by Anonymous Coward · · Score: 1, Informative

    International Conference on Functional Programming.

    Just in case anyone wants to know without clicking through the fifth link to find a page that actually tells you...

  31. What about other high performers? by Anonymous+Brave+Guy · · Score: 2, Insightful

    A more interesting question might be how many offers have gone to someone who's consistently done well two or three times but never won. By my count, there is at least one such person, looking at the most recent contests.

    This year's contest was an interesting problem, and no doubt the winning entry was well done, but there's also an element of brute force involved; look at the hardware Andrew had available. You could make a reasonable argument that this year's winner wasn't decided purely on programming skill, and an even more reasonable argument that doing well in one such contest doesn't say nearly as much as doing well in multiple consecutive ones with different problems to solve.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    1. Re:What about other high performers? by andrewgaul · · Score: 3, Interesting
      You could make a reasonable argument that this year's winner wasn't decided purely on programming skill, and an even more reasonable argument that doing well in one such contest doesn't say nearly as much as doing well in multiple consecutive ones with different problems to solve.
      Andrew Hudson has gone to the ACM International Collegiate Programming Contest twice (the maximum allowed) and placed 21st and 27th, done well in local university contests, and is ranked highly on TopCoder. While it is unfortunate that the contest organizers picked a problem that favored those with expensive hardware, his contest performance has been consistent.
    2. Re:What about other high performers? by Anonymous+Brave+Guy · · Score: 1

      I should perhaps clarify. I'm not taking a swipe at Hudson; his achievements are impressive. I'm just pointing out that there are other people who arguably have a better track record in ICFP contests, and pondering how well they might expect to do out of it.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    3. Re:What about other high performers? by WolfWithoutAClause · · Score: 1

      So far as I can see, out of the top 3 or 4 solutions, his was by far the most likely to work well. Now, that might be partly luck, but given the technical sophistication, and the fact that he actually got his strategy to work, and work well under such tight time pressures; I don't think it was luck at all.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
  32. Inrternational Conference On Functional Programmin by Anonymous Coward · · Score: 3, Interesting

    Somethign nobody has mentioned yet (at least with a high rating) is that this is the contest for the International Conference on Functional Programming, and not only that, from the rules page:

    First prize: $1000, free conference registration for two student team members, and the satisfaction of hearing the judges proclaim your programming language "the programming tool of choice for discriminating hackers."

    Second place language gets: "the consolation of hearing us proclaim your programming language "a fine programming tool for many applications." "

    So, I want to make sure this is clear: At the International Conference on Functional Programming, the judges had to get up a proclaim that "C++ is the programming tool of choice for discriminating hackers."

    I would've loved to be there. Anybody who was at ICFP care to comment?

  33. Re:Inrternational Conference On Functional Program by mvw · · Score: 4, Interesting
    I would've loved to be there. Anybody who was at ICFP care to comment?

    Read this message from a recent thread about the subject on news group comp.lang.functional.

  34. Perspective from Judge's Prize team by onesadcookie · · Score: 4, Interesting

    I was on the team that won the judge's prize, and whilst you can read our report at the link above, I have to say that for us, the key was the human, not the hardware or the program.

    The tracks we did well one were the ones that we were able to hand-drive accurately; the ones we did badly on were the ones where there were simply too many hard turns to make that feasible.

    Despite having a whole university lab full of computers we could have hijacked to run our program on, we only used a single computer for the actual optimizing.

    Also note that although our automatic optimizer was written in Dylan, the visualizer/racing game program was C++.

    If I were going to be controversial I would say that it all just goes to show that humans are better than computers and imperative languages are better than functional ones ;)

    1. Re:Perspective from Judge's Prize team by mvw · · Score: 1
      If I were going to be controversial I would say that it all just goes to show that humans are better than computers and imperative languages are better than functional ones ;)

      Oh yes. Too bad there is no Visual Fortran, it would have crushed the competition. :)

      See ya next year!