Slashdot Mirror
ICFP 2002 Contest Winners Announced
Georgwe Russell writes "The Winners have been announced at the official web site. Looks like OCaml and functional programming have won again, with the 3 member TAPLAS team. There is somewhat of an upset, though. Second place goes to 3-member team Radical TOO, whose entry was written in C! In the lightning round, the virtues of Python as a quick prototyping language were shown in the lightning division's winning entry by the OaSys one-man team. Does the skill of the programmer prevail over the limitations of the language and paradigm used, or is C nearly as good a language as OCaml?"
The proficiency in writing programs means more. :
Most languages are functionally equivalent,
you can even have something like Alma
a program that translate a lot languages to a lot of other languages. It's fun to play with it!
This year's ICFP task, as well as last years, was all about finding a good algorithm. More than anything else, knowing the domain would help. Of course, using a language that provides strong typechecking (like OCaml) or garbage collection (OCaml, Python) allows a programmer to concentrate on the main task. You should not draw too many conclusions from the language that was used for the winning entries.
At the beginning was at.
OCaml is functional, you give the computer rules and then point it in the right direction.
That's not what "functional language" means. The magic of functional programming comes from the (sometimes typed) lambda calculus, in which functions can be passed as parameters. In this vein, we also have easier polymorphism (functions can take a type as a parameter) and fewer "side effects," which could mean fewer bugs.
See Why Functional Programming Matters. For the theoretically inclined, I enjoyed An Introduction to Polymorphic Lambda Calculus with Subtyping.
(Both links can be found on the pages I link to; I don't link to the articles because I don't know your document format of choice.)
Simply put, programming languages are tools. Some tools make certain jobs easier than others, but tools only go so far. The rest is up to the programmer.
In the case of this year's ICFP contest, Team Radical Too did well because they had a good strategy that ultimately fared well in judging. Their robot performs a semi-exhaustive simulation of the possible moves up to a certain degree and then chooses the best move based on the simulation results. (It's a cool approach, and the source code is worth a read.)
It's a compute-intensive strategy, and my guess is that they selected selected C as their implementation language for this reason. They made the decision to sacrifice the high-level flexibility that other languages provide in order to have C's low-level control over how CPU cycles and memory are consumed.
Oh, and then there's luck
Despite how much we like to argue about programming ability and choice of programming language -- and competitions are perfect fuel for this particular fire -- we shouldn't read too much into the results of programming competitions. Luck plays as large role as any.
In the case of the 2002 ICFP Programming Contest, for example, I happen to know that several of the robots, including Team Radical Too's robot, will unwittingly commit suicide in situations where they have the opportunity to push another robot into lethal water that spans more than two board cells. In this situation, the attacking robot will push its victim into the water, killing it. The victim, although dead, appears on the game board the next turn (and is removed from the game on the turn after that). However, the attacking robot's logic fails to account for the fact that dead robots can remain on the game board for a turn before they are removed by the game server. It considers any robot on the game board to be alive -- including the now-dead victim, floating in its watery grave -- and hence fair game for attack. Seeing that there is water beyond the now-dead victim, the attacking bot will try to push it again, thus stepping into lethal water itself and effectively committing suicide. Oops.
Luckily, the judges didn't have any wide spans of water in the map used for the final showdown.
Indeed, chance happeneth to them all.
Easy, automatic testing for Perl.
It's all quite an easy debate really. Some people prefer higher level languages like Python, whereas some prefer lower level languages like C.
What's the difference? The amount of lines you need to write to get the same result.
It therefore goes that the more lines you need to write to get the same result, the more control you get over the program and the computer on which it is running. This means that programs in C can control the computer in better ways than programs written in Perl or Python.
A lot of programmers, like C programmers, think that C, much like Ada, a language to program, in on problems such as objective and the logical ones. An interesting example is the difference between Visual Basic and Visual C++.
In Visual C++, to open a window takes about 104 lines of code if you estimate the number without doing any research like myself. In Visual Basic, you can open a window just by creating a new project and hitting 'Run'. It's easy, and that's why it works.
This is primarily true in the first instance, since there is proof that indicates such, although there is no evidence of this to suggest quasi-otherwise.
mogorific carpentry experiments
whose entry was written in C!
I was just getting used to C#, now we are added C! ?
How is that pronounced? 'see bang'?
How is it different from plain C ?
Jesus was all right but his disciples were thick and ordinary. -John Lennon
But don't take my word for it:
- Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
- Four-fold
Increase in Productivity and Quality: Industrial-Strength Functional
Programming in Telecom-Class Products (PDF) Abstract: The AXD
301 ATM Switch is the flagship in Ericsson's line of Datacom
products. A fault tolerant and highly scalable backbone ATM switch,
AXD 301 has enabled Ericsson to take the lead in the migration of
public telephony networks to becoming true multiservice networks,
offering both quality voice and broadband data services on the same
backbone.... This paper demonstrates how the development of such
systems is supported by the Erlang/OTP technology. The Erlang
[functional] programming language was developed by Ericsson
specifically for the purpose of building fault tolerant, distributed
and complex systems.... The paper demonstrates how Erlang supports
the characteristics mentioned, while offering unusually high
productivity.
- Haskell vs. Ada vs. C++ vs. Awk vs.
... :
An Experiment in Software Prototyping Productivity: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
- Functional languages in microcode compilers (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.
You can find more such papers by tracing references and by reasonable application of Google and CiteSeer.Easy, automatic testing for Perl.
...functional programming wins again...
Of course it does, you idiot. ICFP stands for International Conference on Functional Programming