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.
- gcc 2.96 is actually more standards compliant than any other version
of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable) yet).
It may not be "standards compliant" as in "what most others
are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98
compliant, unlike any previous version of gcc.
- gcc 2.96 has more complete support for C++. Older versions of gcc could
handle only a very limited subset of C++.
Earlier versions of g++ often had problems with templates and other
valid C++ constructs.
- gcc 2.96 generates better, more optimized code.
- gcc 2.96 supports all architectures Red Hat is currently supporting,
including ia64. No other compiler can do this. Having to maintain different
compilers for every different architecture is a development (find a bug, then
fix it 4 times), QA and support nightmare.
- The binary incompatibility issues are not as bad as some people and
companies make you believe.
First of all, they affect dynamically linked C++ code only.
If you don't use C++, you aren't affected. If you use C++ and link statically,
you aren't affected.
If you don't mind depending on a current glibc, you might also want to
link statically to c++ libraries while linking dynamically to glibc and other
C libraries you're using:
g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
(Thanks to Pavel Roskin for pointing this
out)
Second, the same issues appear with every major release of gcc
so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.
Besides, it can easily be circumvented. Either link statically, or
simply distribute libstdc++ with your program and install it if necessary.
Since it has a different soname, it can coexist with other libstdc++ versions
without causing any problems.
Red Hat Linux 7 also happens to be the first Linux distributions using
the current version of glibc, 2.2.x. This update is not binary compatible with
older distributions either (unless you update glibc - there's nothing that
prevents you from updating libstdc++ at the same time), so complaining about
gcc's new C++ ABI breaking binary compatibility is pointless. If you want
to distribute something binary-only, link it statically and it will run
everywhere.
Someone has to be the first to take a step like this. If nobody dared
to make a change because nobody else is doing it, we'd all still be using
gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
- Most of gcc 2.96's perceived "bugs" are actually broken code
that older gccs accepted because they were not standards compliant - or, using
an alternative term to express the same thing, buggy.
A C or C++ compiler that doesn't speak the standardized C language is
a bug, not a feature.
In the initial version of gcc 2.96, there were a couple of other bugs.
All known ones have been fixed in the version from updates - and the version
that is in the current beta version of Red Hat Linux. The bugs in the initial
version don't make the whole compiler broken, though. There has never been
a 100% bug free compiler, or any other 100% bug free non-trivial program.
The current version can be downloaded
here.
- gcc 3.0, the current "stable" release (released quite some time
after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many
others - for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly.
Until the first set of 3.0 updates is released, I still claim 2.96 is
the best compiler yet.
Trolling for GCCWhat's the point?
The ICFP organizers didn't want to work out a foolproof definition of 'functional', so they just decided that any language counts as a functional language. Then if OCaml, Haskell or Scheme win the competition it actually means something, since they were competing against imperative languages too.
-- Ed Avis ed@membled.com
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
And little did I know his monstrosety would grow...
gcc-2.96 is the default version that ships with Redhat 7.1. If you don't like the default, tough cookies.
- 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
I think those two products were already combined into a product called "GrammerSpeeler" because grammar has got to be the most misspelled word on /.
As far as the patent, it was issued long ago as "a micro-computer program to enable the user to alter electronic documents."
--
dman123 forever!
--
dman123 forever!
Filtering out the -1s and 0s since 1999.
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.
Speed of completion is almost always important in real life... because time is money. Programs written in functional programming languages (using the term broadly to include Lisp, Dylan too) not only can be written faster, they are more likely to have the "stability, elegance, and beauty" qualities which you mention.
Because the entries written in functional programming languages always win. ;-)
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.