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?"
I wasn't aware that C was no longer a good language...
Shamefull vanity, but I'd like to know how I did.
Radical Too (runner-up) was kind enough to post their source (after the competition is over, there isn't much reason not to).
But what about me (Aqua Team Hunger Farce)?
Links to source/explanations of many entries can be found on the ICFP site Here
My entry is listed as well. The order of listing is just when people submitted links to writeups, not the winning order.
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
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.
Hello? If you use C++ and don't know about Boost, you've been living in a cave. Come on out and see, it's really cool. Also check out Modern C++ Design by Alexandrescu.
- All of the robots were subjected to a battery of solo games and games against reference robots provided by the judges
- The twenty highest-scoring robots went to the second round and played a number of games against each other.
- The eight highest-scoring robots went to the third round and were subjected to further games.
- Finally, the top two robots battled on symmetrical maps with each being allowed to start from the various starting points an equal number of times (to rule out starting-point bias).
The judges indicated that they would be posting more information later. The conference is still going on (in fact, ICFP is part of PLI, which is going on through 8 Oct), so give the guys a chance to get home and write something up. You'll get the details in due time.Easy, automatic testing for Perl.
Funny that the second place went to Tom Rockicki of dvips and AmigaTeX fame.
I remember that some of his Amiga hacks were uberkool. A realy cool hack of his was a superfast "game of life" cellular automaton implemented on the Amiga's "blitter" coprocessor. Very cool.
-- Anonycous Moward
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.
ah, in this case, k is 0. You declared i, j, and k as integers. Division is defined on integer. In integer division, 1/2 = 0. Now, if you want a compiler that easily switches between integer and floats, thats one thing, but you probably shouldn't refer to them as "int" in that case.
no comment
first of all, for a programming task as small as this one, leaking is not a concern. it isn't something you'll ship to millions of people and have running all the time. if you are in fear of leaking megs of memory in a few days' worth of code and a few minutes of run time, then you have other problems.
second, if i want to free memory, ill free it. if im dumb and forget to free memory a lot, ill use smart types that are freed when they fall out of scope. why would i want to have something freed at some unknown time AFTER it falls out of scope?
The idea that language determines thought to a large extent is called the Sapir-Whorf hypothesis. In its strong form it's been fairly thoroughly discredited.
What is accepted is that it is slightly faster to think of something or to recognise something if you have a word for it already.
If you think about it we are always coining neologisms or borrowing words or making metaphors when our language has no existing words.
Steven Pinker gives a good account in his books.
Fionnbar
There's several possibilities
:) for a version that is not a strictly non-commercial trial version. That's why I ended up using O'Caml instead.
Haskell:
Nice language, but I've never found any implementation that is complete enough to use for real programs.
O'Caml:
Nice language. Nice implementation. Nice library. Currently what I'm using.
Scheme:
Very small lisp. Often used as an extension language (for example in Gimp). It's a common discussion if this is an academic toy language or if it's fit for real programming. I'm not quite sure. Anyway, it's easy to learn (the standard is only a few pages), and there's a nice book for it (The Little Schemer (don't let the cartoons and food receipies fool you, this is one scary book)).
Common Lisp:
Is paradigm adaptive. That is, if you want to write functional, you can. If you want to write imperative, that's nice too. It's my favourite language, but I've had problems finding an implementation that has ok thread support and costs more than a car (no pun intended
I don't think English language will have equivalent translation for: watashi(formal), atashi(fem.), watakushi(formal), ore(rude m.), oi(dialect m.), boku(polite m.), sessha(polite obs.), jibun, unu(dialect), soregashi(obs.), chin(used by noble obs.), touhou(formal), onore(lit), wagahai(rude obs.)
They all mean "me," but used in different context.
Same applies to "you." like kimi, kisama, atana, omae, temee...
The reason why there are so many ways of addressing one another is because Japanese human relationship is never even.
And by using Japanese language, notion of respect level somehow slips in, and thus Japanese speaker will not have the concept of simple "you and I" even relationship. Because they lack the concept of simple "you and I," title names or names are more often used to address others instead of "you," "he," or "she" to clarify the respect level in the sentence.
// only the code never lies.
From the Caml Faq
The main reason is historical: Caml was invented before SML.
The Caml language is issued from the original ML language, invented by Robin Milner in 1978, and developped jointly at INRIA from 1981. The first Caml compiler was written in 1984, and distributed from 1985. Standard ML was not yet invented, and Caml's syntax was similar to the syntax of ML V6.2, whose compiler was used to compile the first Caml compiler. When the syntax of Standard ML has been defined, Caml kept its own syntax, for several reasons. The first reason is questionable and subjective: we thought that SML's syntax was not a major improvement of the original ML syntax (hence of Caml's one). The second, more fundamental, reason is that we thought the language not to be mature enough at that time to be completely defined and fixed by a standard; we are still doing some progress on the understanding of some features of ML, and these progress may imply some important modifications of the language (let's cite the type checking of imperative features or the semantics and type checking of modules). In addition, we wanted to be free to add some new constructs (and indeed we did it, e.g. ``for''loops, ``try with'' and ``match with'', character constants, access to vectors and strings, ``mutable'' annotations for records, ``when'' clauses in pattern matching). This relative freedom with respect to the syntax allows the emergence of new variants of Caml: for instance the Caml Light and Objective Caml systems have their own extensions to the core syntax of Caml.
Hence Caml has its own syntax.
More interestingly caml has a pre-processor(camlp4)which allows to write in various other syntaxes. E.g. there is a Standard ML syntax, as well as a lisp-ish syntax.
They both have nice documentation. They are so similiar I doubt it makes a lot of difference. The nicest new programmer ocaml documentation is The Oreilly Book Developing Applications with Objective Caml. With the exception of Ocaml's object oriented features, most ocaml documentation can be used w/ SML, and vise versa.
For whatever its worth, camlp4 gives you a nice macro system too. I don't know how it compares w/ common lisps, but it does give you static checking of your macros and let you work at the abstract syntax tree level.
If you had ever taken abstract algebra, you would understand that, although the integers are a ring, they are not a field. Therefore, they do not have division, bucause they do not have (in general) multiplicative inverses. What the operator "/" does in C (conceptually) is to apply what is called the division algorithm, guaranteed for all principal ideal domains, IIRC, which solves the equation a = bq + r (where r b) for q given a and b. Therefore there is in fact a mathematical basis for integer division.