Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming Announcements IT Technology

8th Annual ICFP Contest 72

mauricec writes "Think your favorite programming language is the best one out there? Put it to the test in this year's International Conference on Functional Programming's annual Programming Contest. The contest is coming up in a little under 4 weeks! This year's competition rewards programmers who can plan ahead. As before, we'll announce a problem and give you three days to solve it. Two weeks later, we'll announce a change to the problem specification and give you one day to adapt your program to the new spec. More info on the contest and prizes is on the contest's web page."
This discussion has been archived. No new comments can be posted.

8th Annual ICFP Contest

Comments Filter:
  • by nhnfreespirit ( 809462 ) on Monday May 30, 2005 @07:22AM (#12675718) Journal
    If the original program can be written in 3 days, chances are a good programmer can write a new one that matches the changed specifications from scratch in one day. Is this cheating? :-P
  • Not a bad exercise! (Score:5, Interesting)

    by nhnfreespirit ( 809462 ) on Monday May 30, 2005 @07:32AM (#12675748) Journal
    We actually did just this as an assignmet in a software engineering class a while back. We had to write a simple life simulator, and then a new assignmet was handed out that changed the original specifications.

    The last part of the assignment was to make our life-forms compatible with that of at least one other group. This last part proved quite interesting as, even though the critters were technically compatible with the other groups environment, many of the assumptions our two groups had made about the world (such as sight radius of each creature, how much food a creature needs, how fine grained the world was...) made the creatyres behave rather weird.

    Still, it is a good way to be forced to write code that is easy to refactor from start!
  • by SlightOverdose ( 689181 ) on Monday May 30, 2005 @07:34AM (#12675756)
    Hmm. Two weeks to complete a project, followed by a changed spec the day before going live.

    sounds like some of my clients.
    • by ^DA ( 82715 ) on Monday May 30, 2005 @08:06AM (#12675890)
      Change of spec sounds like real life to me. Customers rarely know excactly what they want before they have a working system up and running. THEN they start to see the possibilities.

      Frustrating? Yes! But we have to live with it. We just need to make them understand that the project will be delayed and it will cost more and why this is so if they change the specs late in the project.

      Our job as developers is to make the system easy to change bacause we all know this will happen.

  • Wow (Score:5, Interesting)

    by CastrTroy ( 595695 ) on Monday May 30, 2005 @07:38AM (#12675771) Homepage
    This is just like in real life. Design a program to spec, and then 1 day before launch, change the requirements. Is this the kind of activity we should really be promoting? Maybe we should give well laid out requirements, and whoever follows them the best, wins. Not only would following the requirements be important, but also not exceeding the requirements, and adding a bunch of stuff that wasn't asked for, would cause you to lose points.
    • Re:Wow (Score:4, Interesting)

      by NoseBag ( 243097 ) on Monday May 30, 2005 @07:47AM (#12675805)
      Is this the kind of activity we should really be promoting?

      You answered your own question in your first sentence: "This is just like real life."

      Humans (and spec writers, too!) make mistakes and sometimes overlook aspects of a desired requirement that are important. Recognising this and being ready to deal with it is part of the job for any professional in any industry.
      • Re:Wow (Score:4, Interesting)

        by CastrTroy ( 595695 ) on Monday May 30, 2005 @07:57AM (#12675849) Homepage
        I do realise thats its kind of important to make a program that can easily be changed to meet changing requirements. Even if it follows spec, and does what the customer wants today, within 3 months, the customer will want it to do a bunch other things, or do some things differently.

        I was just kind of pointing out that this contest brings to light one of the most frustrating parts of designing software in the first place. This is one of the things that makes it so hard to get right. If you told a civil engineer to build a bridge, and then half way through building it, told him you wanted it to hold twice as many cars, and be a draw-bridge, instead of a suspension bridge, well, I think that he would basically have to start over from scratch, and the project would of course be over budget, and take longer then originally expected. With software, there is less of an impact, but people still have to realize the real impacts of trying to change things at the last minute. People who don't really know much about software will look at competitions like this, and think that they don't really have to worry about changing requirements, because programs can be changed easily, without any ill effects.
        • Do you really think that people just change requirements on a whim without any thought to the impact on time and budget? Maybe the cost of not changing the requirements would be more costly because you're no longer solving the business problem the way it needs to be solved.

          To use your analogy, rebuilding the bridge might be worth it if large ships (read: lots of money) now need to get through.
          • Do you really think that people just change requirements on a whim without any thought to the impact on time and budget?

            Yes, it does happen. Generally from a "on-high" business process change where I.T. is not consulted. Many managers do not understand how these decisions affect I.T. systems. Also, government policy changes will have huge affects when dealing with a highly regulated industry.

        • The thing is, in the scenario you described, you wouldn't have the option to change the kind of bridge after it was in construction.

          This is a lot of what ends up happening to software. A simple project gets completely finished, but ends up being too rigid and when someone wants to add functionality to it, they end up having to rewrite the whole damned thing.

          This is why we moved from more functional languages, to more Object Oriented languages. If someone writes a program abstract enough, then adding fu
          • Re:Wow (Score:3, Informative)

            by jjc2222 ( 100453 )
            You are getting "procedural" programming confused with "functional" programming. Functional languages generally refer to languages that concentrate on the evaluation of expressions with no side-effects rather than statements that modify data. Examples of functional languages are:

            Note that C and Pascal are decidedly not examples of programming languages designed for functional programming. Wikipedia's page is a decent starting point for learning about this.
            http://en.wikipe [wikipedia.org]

          • The thing is, in the scenario you described, you wouldn't have the option to change the kind of bridge after it was in construction.

            Whether you should be allowed to do it with software is a good question, too. Obviously there's more scope for reusing a line of code than a 10 tonne block of concrete, but code reuse is one of those semi-mythical creatures that you rarely see in real life. It would be fascinating to know how many "programmer error" bugs that cause loss of data, security breaches, etc. oc

            • My apologies, I misread and misinformed the whole thing; I was thinking the whole time proceedural and not functional.. No posting on /. in the AM hours for me :).
          • > This is why we moved from more functional languages, to more Object
            > Oriented languages.

            Huh? No. Most people who moved to more OO languages were coming from procedural/imperative languages, not from functional languages.

            > If someone writes a program abstract enough, then adding functionality
            > is as simple as throwing in a new object, inhieriting, and you're done.

            Object-orientation isn't the only kind of abstraction. The FP equivalent to re-writing a base class is to pass a different clos
    • Re:Wow (Score:4, Insightful)

      by jorleif ( 447241 ) on Monday May 30, 2005 @07:48AM (#12675806)
      Is this the kind of activity we should really be promoting?

      Don't you just hate it when competitions are similar to real life, instead of promoting some "pure" academic ideal?
    • >>Maybe we should give well laid out requirements

      Ahh, but that would require the contest directors (aka, stakeholders) to put forth the effort to create coherent and complete requirements (and when does THAT happen?!)

      The implication to 'whoever best' is that the task is non-trivial enough to end in enough of a gradation to separate out even the top tier percent into a clear winner. Non-triviality of this level would be an effort ten-fold larger than the actual programming. Bullet-proof specifactio
    • Yeah man. We wouldn't want to have a competition which tests skills useful in the real world, too.
    • Re:Wow (Score:3, Insightful)

      by be-fan ( 61476 )
      This is like real life. And I disagree that this is something we shouldn't be promoting anyway. There are a lot of areas where its impossible to define a detailed specification before hand. Take your average DARPA project. In many cases, nobody knows what the final solution should look like, or even what is possible given current technology. In such situations, the specifications are vague and often changing, because the process of doing the research makes the end result more clear.

      Part of the reason that
  • FP (Score:5, Insightful)

    by mistersooreams ( 811324 ) on Monday May 30, 2005 @07:39AM (#12675777) Homepage

    There are some comments already saying "if the program could be written in three days, couldn't they write a new one from scratch in one day?" The answer is that a very fast programmer probably could. But what would the point be? The object of this exercise is to show off just how generic a program written in a functional language can be. It really is possible to abstract everything, leading perhaps to the famous paradox "Everything can be solved by adding another layer of abstraction, except having too many layers of abstraction."

    Putting that aside, I think this is a great idea for a competition. I hadn't heard of it before this one, and have only recently got into functional programming myself. I'm a new-found convert to ML, and find it interesting to be forced to think about a problem in a completely new, and usually recursive, way. ML also has some imperative elements but I prefer to avoid them as far as possible. I'll attempt to make an entry to this contest, although I doubt I'm at the relevant level of expertise yet.

    I'd be interested to hear what languages other Slashdotters think would be most appropriate to a contest like this. Lisp gurus, start your engines!

    • FP
      There are some comments already saying...
      If there are already some comments, how is this a FP?
      • by Anonymous Coward
        FP stands for Functional Programming.

        Relax, with your WTFs...
    • PHP comes quickly to mind. Many, many people call it a Object Oriented language, but when it comes down to it, it's really just scriptable C. Perl, Parrot and Python are all OO throwing them out of consideration. BASIC (the non-visual flavors), Pascal, C, and Haskell are all really good choices as well.

      And if you really want to have some fun, write it in assembly, though this option will make you very machine-conscious.
    • I'd be interested to hear what languages other Slashdotters think would be most appropriate to a contest like this. Lisp gurus, start your engines!

      The most appropriate one is probably the language you know best (coupled with the one most suited to the problem -- if speed is a big plus, you're not going to want to deal with, say, PHP, and if concurrency is a big issue, you might want to lean on Erlang or Oz). Despite the name of the contest, you don't need to use a functional language: the winners of last
    • "Lisp gurus, start your engines!" -- NOT!

      I think Forth.
      Small core, fast, functional, modular, & universal.

  • ...is that you have to write a program to kill Microsoft
  • by jb_nizet ( 98713 ) on Monday May 30, 2005 @08:14AM (#12675932)
    In my (short) experience, I've found that planning ahead is, most of the time, a bad idea.
    It takes time. It makes the code more complex than it could be, and thus less readable and maintainable. And when the spec finally changes, it changes in a way that makes this additional layer of complexity useless, and another layer is added on top of it.
    • Good luck when you get into more complex problems.

      For simple, algorithm-scale problems, planning isn't really required, it's done implicitly by the problem itself. Things like solving questions are often algorithmically scaled. "You have N sailors with numbers pinned on their shirts from 1 to N. Starting with sailor 1, you go around in a circle, telling every Mth sailor to leave the circle. If you continue forcing sailors out of the circle, what is the number of the last remaining sailor?".

      The problem i
      • You're describing what planning means (or designing, or whatever).
        I know that planning is important. What I consider doubtful is planning *ahead*, i.e. designing for more than what the application must do, just because the requirements might change in the future.
  • by elgee ( 308600 )
    I enjoyed programming in Lisp, but it fell out of favor. Now I have to use Javasp.
    • > I enjoyed programming in Lisp, but it fell out of favor.

      Lisp fell out of favor because it was ahead of its time. On the hardware avaialable in 1975, a language such as C was able, by not providing any useful highlevel abstractions, to wring useful performance out of the hardware. So naturally such languages almost completely took over.

      The up-and-coming languages that are gaining favor now actually have more in common with lisp than they do with C, in a lot of ways. Not everything, obviously, and s
  • by Tom ( 822 )
    Can I write my program in C and look whether or not I'll be able to adapt it just as quickly?
    • It's not restricted to functional languages. In fact, teams using C have done quite well in past years.
    • > Can I write my program in C and look whether or not I'll be able to
      > adapt it just as quickly?

      You're going to write a non-trivial program in three days, in C? Is that even possible? Bear in mind, this competition is being held by functional-programming nerds, so the problem is likely to be the sort of thing that's most easily solved by using continuations for backtracking or some such technique.

"Ignorance is the soil in which belief in miracles grows." -- Robert G. Ingersoll

Working...