Slashdot Mirror
4th ICFP Programming Contest Announced
gdon writes: "So you are the best and fastest coder in town? Take a chance to exhibit your skills and maybe win a prize at the 4th ICFP programming contest at the International Conference on Functional Programming. The programming challenge task will be published on July 26, 2001 at 15:00 UTC and program submission ends 72 hours later." Check out the previous contests: 1998, 1999, or 2000.
Clearly, Unlambda is the only reasonable representative for this competition from the field of performance art programming. I hope to see at least one submission to this ICFP thing written in Unlambda, and i am certain that if any Unlambda programs are submitted they will trounce any competition written in Brainfuck, Befunge, INTERCAL, or perl.
Onwards, my brethren! Let us crush all who espouse the false paths of named variables and iterative memory usage! CHURCH NUMERALS ARE THE ONLY WAY TO FIND ENLIGHTENMENT! THE ONLY!
Sorry. I've got something of a headache.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
- An ominous headline
- A set of unverified trivia.
- A conspiracy theory
- A mention of Linux
- A mention of Microsoft's feelings toward Open Source
- A sarcastic closing remark.
The script even begins populating the discussion with lengthy posts from the same account both extolling the virtues of and deriding Microsoft.Got Rhinos?
Here is a useful description.
illegitimii non ingravare
the BBspot Slashdot Story Generator.
BlackNova Traders
Some people there were complaining that the benchmarks were trivial and artificial and unrealistic, and lamented that it was impossible to get people to write real programs for a benchmark.
I think that's exactly what the ICFP contest is.
They use quite real tasks. Last year the task was to write a ray tracer with a build in programming language for building the scene models and implementing procedural textures. In 72 hours!
The resulting programs were generally several thousand lines of code, and the really interesting thing is that at least for the top entries (and I think for our Dylan entry as well :-), it is actually very interesting and high quality code.
The entries are not judged on the aesthetics of the code itself, but perhaps they should be. Or, perhaps, keping the code clean is the key to allowing a team of people to all work on the same code for 72 hours and complete a quite significant task in that time.
Because it is run in conjunction with the International Conference on Functional Programming.
Yes, these are people who believe that functional languages are better, and they fully expect functional languages to win.
But from what I've seen from the past contests, the contest tasks are not inherently biased towards functional languages, and good programmers could well win using C or C++ etc. Or, at least, they could if they could manage to write fast and bug-free code quickly enough in those languages. In fact, some C programs have done quite well in previous years -- they just haven't managed to win.
Maybe that's only because the best C/C++ programmers haven't entered the contest in the past. Or maybe functional languages really are superior.
There's only one way to find out. Gentlemen, start your compilers!
You don't have to use their gcc. They actually encourage you to submit a statically-linked binary, rather than build on their machine.
I encourage people to enter this contest. It's fun! Last year I put together a small team using Dylan and we had a ball even if we didn't win.
After being /.ed last year there were around 800 teams registered, but only about 5% of them actually submitted an entry. I think that's a pretty poor showing from the /. crowd.
Speed of completion is not important. ... now that computers are running life-support systems and the like, there is no room for error.
;-) Seriously, speed of completion is always one of the three possible priorities of any software project (or hardware or general engineering project)... 1) time, 2) features, 3) quality. Pick two of the three that are important in any given project or task and then you've got something you can "manage" in the true sense of the word. You're right that life-support systems should not care much about the "time" aspect of development. But time is more critical than "features" in some cases and it's more important than "quality" in some cases.
You're fired.
Every project's requirements (part of the discipline of engineering is recognizing this) will dictate priorities. A couple of examples in these terms might be...
Creating life-support software? Great, make sure it has all the necessary features and it's of "perfect" quality. If it ships late, that's probably fine.
Creating a baseball video game? Great, make sure it's done in time for opening day of the new season to maximize fan demand and competitive advantage (you're up against 6 other similar products that will ship near the same date), and if it's released for a console (ie, a million units will ship on CD-ROM or catridge with no update ability), make sure it's also of near-perfect quality. Leave out features if necessary to get it out by the hard deadline date.
Open-source examples are left as an exercise to the reader... But remember that if your product's main target is initially developers, bug count isn't a show-stopper, so publishing a bug database and acknowledging that quality will have to catch up later can be quite acceptable.
I bet the winning program will be coded in befunge
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Check out topcoder. They host frequent online Java programming competitions.
Someone has won $100,000 through their collegiate tournament.
A prize of unlimited bragging rights. Finally, something _worthy_!
Of course, first prize also includes:
Peer recognition: Finally, the contest judges agree to state at least once during the presentation of the awards that the winning team's programming language is "the programming tool of choice for discriminating hackers."
Which I daresay will cause a fight to break out, much like this brawl.
For the winning program to have been written in Brainfuck.