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?"
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.
-Kevin
Winning the contest is more about being a good programmer than about the particuliar programming languages.
But then again, you can assume a good programmer would pick a good programming language.
This post was compiled with `% gec -O`. email me if you need the sources
That about clinches it. A lot of people really look down upon those who use any coding language that in any way simplifies the coding. The way I've always seen it is thus:
Visual Basic is a very nice language for coding GUI-based applications. Newer versions have increased speed and performance such that there's not really a difference (exempting the included DLL's) between a standard office-type app made in VB and one in C++. If you want to get complicated and rip into the windows API, then you're probably doing something that may require C++, but VB often even handles this nicely. It interfaces much more nicely with the C-based DLL's than it used to in the past.
My biggest peeve is the syntactical differences in compative operators and math. There was a time when I love VB, but now I truly hate having to do a "myvar = myvar+1", or the fact that you can't do something like "var1=var2+var3" (in VB that would give a boolean).
In arguement for VC++, the wizards can handle a lot of the windowing/GUI stuff for you. I think that if if gave you some nice understandable error messages when you screwed up things might be a lot nicer. (it sucks when you get an ambiguous error message on line 2023 caused by a mistake on line 101).
Since I've learned C++, I prefer it when possible. I have no huge qualms about writing a GUI in VB, or even a hybrid project with C++ DLL's linked to my VB GUI's. Every coder has their place. Just because one can program C and Fortran doesn't make them any better than a VB programmer. In a timed-trial for a small GUI app, the VB programmer would likely stomp the C progammer.
If only MS could program better error messages... Error on line 342: unknown thingamabobber executing blingconfangler - phorm
as has been previously noted, the functional vs. non-functional distinction is only one of several, e.g., declarative vs. imperative, strongly-typed vs. weakly-typed, compiled vs. interpreted, etc.
the promise of all newer programming languages is that they are easier to develop, understand, and maintain, because the programmer is elevated to thinking about the "big picture".
i think it's possible to do great things in old languages like C. what it comes down to is, you need discipline. if the compiler/language design has discipline for you, great. otherwise, if you have alot of experience with alot of languages, and are anal, you'll do ok in a small group of similarly talented anal people. in a larger group or project, any not-automatically-enforced discipline will eventually be broken.
unfortunately (?) i still do most of my programming in C/perl. that's because a) i need the solutions i'm developing to work 100%, and i can't afford to run into obscure under the hood problems in still-maturing technologies like ghc, and b) i like to leverage the huge body of existing libraries out there, and c) i have only worked on small projects (
-- p
That's just a few minutes of brainstorming, I'm sure there are more.
-Kevin
Of course, it does. A bad programmer, or even a single average programmer, would be totally unable to finish the contest. You have to be proficient. Similarily, if you have to spent 10 hours chasing an obscure malloc or a subtle temporary variable passed on the stack reference - bang bang bang - you're out of the contest. The quality of the programming language is essential.
Similarly, a program that's developed in a short period of time by a small team tells you nothing about how readable the programming language is. Some languages are easy to write in - but a bugger to understand a year later.
To a large extent, it does. Because there is absolutly no time to waste to talk to each others about details. Writing unmaintenable code is possible when you have a fixed problem and plenty of time - the ICFP's top entries are often those who were enhanced in the last 10 hours of the contest - there is no room to have unmaintenable code here, you have to understand it, change it quickly, without any bug. Add a bug, and yes, you're out of the contest again. Especially since, in all ICFP contests, it is *always* possible to improve one's program.
The only thing ICFP is not testing is large scale programming.
Still, contests are fun - and that's enough to justify their existance.
Try to participate, you will be enlightened.
So, two parents divorce, and each gets half.
Problem is, they've only got one kid.
How much does each parent get?
The story of Solomon points out that there are indeed discrete, indivisible quantities in this world that humans deal with on a regular basis. Though physically, the "type conversion" of the child into two bloody halves is possible, it's not likely what any programmer or parent wants.
All sorts of other discretes exist for programmers. How many packets can I send, given one hour? 4/10th's of a packet is not a packet sent. How many widgets can be produced? A widget almost produced can't be sold. And so on. There is reality other than floats, good sir.
--Dan
And no, I don't think your description captured functional languages very well - as you say, it sounded more like Prolog. Besides, the "rule-based" appearance of some functional languages (notably Haskell & the ML family) is really mostly syntactic sugar. Scheme, which is much closer to the pure lambda calculus on which most functional languages are based, doesn't have such a rule-based appearance.