Slashdot Mirror
8th Annual ICFP Contest
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."
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
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!
apterous.org
No, but (from your link) it does "change its structure and design, and remove dead code, to make it easier for human maintenance in the future."
Refactoring might be a sensible thing to do during the two weeks between the first and second phases of the competition.
Having said that, from my (limited) experience, you tend to need less refactoring in functional programming languages than in imperative (or object-oriented) languages.
Matt
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?
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.
This is often true because functional languages are not very abstract. They tend to be very mathematic and algorithmically driven.
Object Oriented design requires one to think in a way more human, and less mathematic/computerish. We classify things as "objects", we give objects "methods" and "properties". Functional languages only have properties (coeffecients and inputs, etc).
Refactoring OO programs tends to be a hobby, more than a necessity, as I find it. Every now and again you'll hit something that greatly speeds up the code, but more likely it just makes the code either look better, or more usable if you were to plug it into something else, neither of which I end up doing very much.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
"Hey, significant other, I'm not into it for the money"
Worked for me. YMMV.
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 these ICFP contests are held are to demonstrate the strengths of functional languages. Traditionally, exploratory programming and rapid refactoring has been considered one of these strengths. Thus it makes sense to have a contest to demonstrate these strengths, especially when the conditions of the contest are applicable to so many real world scenarios.
A deep unwavering belief is a sure sign you're missing something...