Slashdot Mirror
ICFP 2005 Programming Contest Results
Fahrenheit 450 writes "The results of the The Eighth Annual ICFP Programming Contest are in, and it looks like this was the year for Haskell and Dylan, with Haskell programs taking first & third prizes, and Dylan claiming second prize and the coveted Judges' prize. This year's contest was a simulated game of cops and robbers, with a twist to the rules thrown in after the participants had submitted their initial entries. Step through the transcripts of the contests or just download the PDF version of the presentation slides and tell us all how you could have wiped the floor with the winners using your carefully crafted COBOL or awk submission."
There was no requirement to program in a functional programming language. One guy wrote his cop & robber as shell scripts, although it failed in both rounds.
You can use imperative languages too. That's the neat thing about the tournament -- given a choice, most of the folks choose languages that offer more expressivity than the typical imperative language.
There have been "C" programs that won previously, I believe.
http://www.thebricktestament.com/the_law/when_to_
The ICFP contest accepts submissions written in any language. In this year's contest, there were 34 C++ entries (the most of any language), 20 Python, 19 Java, 10 C, and 9 Perl entries -- of the "functional" languages, there were 21 OCaml entries, 16 Haskell, and a mishmash of "others" like Dylan, Erlang, scheme, etc.
-30-
The language isn't the important thing, although you should of course start with an easy language (like BASIC - **not** Visual Basic, or anything like that, mind you. Also, if you do use BASIC, try to use a version of it that has true subroutine calls). Don't worry about the capabilities or performance of the language - your only concern at this point should be how *simple* it is for a beginner. You have to learn the basics of programming first; don't worry about a do-it-all language.
Second, have a grand overarching goal in mind, but choose *ridiculously easy* programs to start with. Start with "Hello World". Move on to some variable assignment and looping. Learn arrays, and work them in. Then, move on to things like simple sorting algorithms, lookup tables, etc. These may not be the most fun to write, but they'll get you comfortable with programming.
When you want to start with things like graphics, again, *keep it easy* (again, a language like BASIC would be good - you don't want to be messing with GL or any window API functions at this point). A good starting graphics program is to make it snow, one single-pixel snowflake at a time, with the snow falling top to bottom and not sticking around. Then, steadily improve the program - have multiple flakes fall at once, have them blow randomly in the wind, use more than a pixel for them, have them accumulate at the bottom, etc. Fractals are also often good starting graphics programs. A neat iterative fractalline program involves taking any image, and XORing it with itself shifted a couple pixels in direction, the direction being determined by looping through preset directions that sum up to zero (example: [(-1,-1), (2,-1),(-1,2)]); you get strange ghostlike images resembling the original pop back up later as things fade to static.
From thereon, you should start getting frustrated with the lack of power and performance that your starting language has. What language you move onto is, of course, a contentious issue; however, a general, *very rough* guideline is that you want languages like python and perl for writing programs that "get stuff done for you", while you want languages like C/C++ and Java for programs that "you run and interact with". This is, of course, an extreme overgeneralization, but there's some truth to it in practice.
Don't get obsessed with "learning the language". Learn what you need from it. I'll put it this way - in college, I took one course on compilers and interpreters; everything in the course was done in 'scheme'. The first week was spent learning the language - one week, thats it. After that, we worked on the course material.
When you have time, and you're already comfortable with what you do know, learn more. Things to especially focus on are things related with programming styles, reducing maintenance, and enhancing clarity - for example, if you learn what you need in C++, when you have a chance learn about templates, vectors, maps, the importance of const, etc.
When you feel comfortable with your programming abilities, contribute to an extant project. Don't jump in and tell them how things should be, however - find out what *they* want done, and do it *their* way. Learning how to program in collaborative efforts is very important.
... in Siberia, where Putin killed a fish with a speargun. He later claimed it was killed by Ukrainian separatists.
As others have said, the problem is not languages. However, rather than offering vague suggestions about "motivation" or "picking a goal", I have some concrete advice: try taking a look at How to Design Programs. It's textbook by some of the best minds in CS education, and its goal is to teach you how to break down and structure problems, and create programs which solve those problems - not just to teach you a language. It'll teach you to think like a programmer. Which, quite frankly, sounds like what you need. Better yet, it's freely available online (so you can easily give it a testdrive), although I'd recommend picking up the print version if you decide you like what they have to say (for the sake of readability if nothing else).
Here is a graphical simulation of a game that was played. The red guy is the robber, and the blue guys are the cops. There's a key available if you want a better idea of what's going on.
Ask me about repetitive DNA