Slashdot Mirror


LiveCoda, Real-Time Coding Competition

Robert Shelton points out this "debrief" from ESCI LiveCoda 2006, a live programming competition. From the article: "On Wednesday the 24th of May at Loop Bar in Melbourne (Australia) fourteen teams of programmers gathered for the first ESCI LiveCoda real-time programming competition. Possibly the first performance based real-time programming competition. Before a packed night club with live music, each team had just ten minutes to write a program which could correct a corrupted image." (Here's a mirror of the LiveCoda site).

15 of 95 comments (clear)

  1. I'm sure that this will make the IT trade cooler by Trigun · · Score: 5, Funny

    Next, can we have Sergei Brinn found passed out in the bathroom stall with six hookers?

  2. "How long, O Lord?" by Black+Parrot · · Score: 3, Insightful

    Why this fascination with speed?

    When are people going to start programming contests where the award is given for something that's actually useful, such as fewest bugs, most readable, best re-use of existing code, etc?

    --
    Sheesh, evil *and* a jerk. -- Jade
    1. Re:"How long, O Lord?" by Ed+Avis · · Score: 4, Insightful

      Competitions already are judged on 'fewest bugs'. Indeed, some competitions disqualify any entry that has any bugs found in testing. But all the other criteria you suggest are subjective. I think speed is a pretty good judge of programmer ability; someone who can hack up a correct program in 10 minutes stands a good chance of writing a correct, clear and maintainable program in an hour.

      --
      -- Ed Avis ed@membled.com
    2. Re:"How long, O Lord?" by SpeedBump0619 · · Score: 3, Interesting

      "someone who can hack up a correct program in 10 minutes stands a good chance of writing a correct, clear and maintainable program in an hour."

      Patently false, for a number of human reasons:

      1) Programmers are are fast are generally easilly bored. This leads to wandering focus.
      2) Programmers who are fast often approach problems in a strange way. This can lead to convoluted and confusing implementations.
      3) Programmers who are fast rarely see value in commenting. Why comment when I can rewrite faster than I can reuse?
      4) Programmers who are fast are usually impatient, and don't work well with teams. I *like* this competition because it has some focus on teamwork, but I'm generalizing.

      For such simple problems as are being solved in this competition most of these problems aren't problems. But all of these things will eventually lead to unstable, unmaintainable codebases. I'd prefer to have someone who is good at code re-use, who is good at seeing the complex parts of problems and who is good at getting the right architecture the first time. None of these things are tested in this competition.

  3. The first? by bsartist · · Score: 5, Funny
    Possibly the first performance based real-time programming competition.
    In my day we called those "job interviews", and first prize was paid out in weekly, bi-weekly, or monthly installments.
    --
    Lost: Sig, white with black letters. No collar. Reward if found!
  4. Geeks? by Ramble · · Score: 5, Funny

    In other news geeks have been spotted in a bar near Melbourne, it's rumored to be the first documented case of geeks in an alcoholic establishment and will provide scientists with invaluable data on the migration habits of Australian Spotted Geek (Geekus Oceanus).

    --
    "Oh boy"
  5. From the FAQ by Life700MB · · Score: 5, Funny


    9) Will I have access to a Dvorak keymap?

    Yes.

    10) Were you really asked about Dvorak keymaps?

    Yes.


    --
    Superb hosting 20GB Storage, 1_TB_ bw, PHP, mysql, ssh, $7.95

  6. Oh the possibilities by kay41 · · Score: 4, Funny

    I shutter to think of the pickup lines that were spoken throughout the evening. After all, us programmers are foreign to this "club" environment. What is this "music" you speak of anyway?

    --
    arl with a k - a blog of mine.
    1. Re:Oh the possibilities by MrAnnoyanceToYou · · Score: 3, Funny

      "Me so Hooorney. Me drool you long time. Computer Fixey Fixey five minutes."

  7. Personally by celardore · · Score: 4, Funny

    Personally I can think of better things to do in a nightclub, with live music.
    And, if I'm in a nightclub chances are I'm in no fit state to do any coding. Actually, I've had an idea - a coding competition where you have to drink eight beers first!

    1. Re:Personally by slashflood · · Score: 3, Funny
      Actually, I've had an idea - a coding competition where you have to drink eight beers first!
      Erm... I wouldn't even start coding without eight beers first..
  8. Re:Did the choice of language affect the results? by Fahrenheit+450 · · Score: 3, Insightful

    But for something like this, you're mainly limited by the contestants' familiarity with the problem domain.
    With this particular competition (which looks to consist of reading in a simple image format, like PPM then applying a couple of simple transformations then writing the new file back out), the code isn't going to be too terribly different between most languages, and therefore the higher expressiveness of something like Python or OCaml wouldn't really get a chance to shine.

    --
    -30-
  9. This is what people actually believe? by imaginaryelf · · Score: 3, Interesting

    Sorry. I can't agree.

    Having spent 20 years in the programming profession, I've worked with a lot of programmers. The speedy ones are usually exceptionally smart, but their code is completely unmaintainable, no matter how much time they are given to write it. If you work any time in industry, you'll know that 90% of your life is maintaining or improving upon code that others have written, so the speedy ones actually hurt overall programmer productivity for the team.

    I'll take a slow and methodical programmer over a Speedy Gonzales anyday.

    1. Re:This is what people actually believe? by joebob2000 · · Score: 3, Insightful
      The counter-generalization: The speedy ones are usually exceptionally smart, but their code is completely unmaintainable, no matter how much time they are given to write it, because the other 9/10ths don't understand the code enough to maintain it. Of course this is the fault of the 1 smart programmer. Why? because they are outnumbered 9 to 1. The exception? when the smart programmer becomes VP of engineering.


      I know plenty of smart, fast programmers that write clear code and follow the rules. Sometimes the best ones will write something that most others have a hard time following, not because it is "sloppy", but because they are more talented. They also find and fix plenty of bugs that the other 9/10s made in their "maintainable" code. I have seen times where a super programmer correctly debugs a regular programmer's code in a design review sight unseen, just from the description. I have also seen regular programmers say "I checked it", or argue with a super programmer, until he gives up in and takes 10 minutes to find the bug and fix it himself.


      What's my point? I don't have one, except maybe don't be a hater just because you can't hit the ball like Tiger Woods.

  10. I was there, more info by enos · · Score: 3, Informative

    I went to this thing for a little bit, and while nifty, I don't see why thousands of geeks need to know about it...

    Anyhow, it went down like this: four machines with an editor common to all of them, with teams of 2-4 people. They were given a 200x200 image file consisting of simple rgb triples. (200 100 50\n100 133 212 etc, real simple). There was a transform done to it that they had to reverse. The ones I saw were some color rotations/swaps and rotations in increments of 90 degrees. The program had to read in the file, invert the transformation, and output the correct image in the same simple format.

    The teams could pick whatever language they wanted. I saw C, C++, Python and Java before I got bored and left. The admins had a system set up that it would compile the code at certain intervals and print out the errors on the screen, or the resulting image if it compiled successfully.

    The teams didn't really have trouble writing the code. It was no longer than a screen worth, and they seemed to get that in about 2.5-4 minutes. They spent the rest of the time trying to figure out what the transformation was. They'd try 10-15 different color rotations/swaps combos before the time ran out. They didn't get the correct image in advance, but they were all photos from around the Melbourne area and it was easy to tell what it should be.

    If I had heard about it with enough time in advance I would have taken some friends and entered... ah well.

    --
    boldly going forward, 'cause we can't find reverse