·········@gmx.net (thelifter) writes:
> Did Lisp ever win this contest?
It's not languages that win this contest, it's programmers.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche wrote:
> ·········@gmx.net (thelifter) writes:
>
>> Did Lisp ever win this contest?
>
> It's not languages that win this contest, it's programmers.
Programmers who use languages other than Lisp :)
Oleg
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
A long time ago, in a galaxy far, far away, Nils Goesche <······@cartan.de> wrote:
> ·········@gmx.net (thelifter) writes:
>
>> Did Lisp ever win this contest?
>
> It's not languages that win this contest, it's programmers.
.. And to date, none of the winning programmers have been using Lisp.
The nearest that it has come is if you squint at things sufficiently
sideways to consider that Dylan might be considered "a Lisp," as a
Dylan-based team got honorable mention (last year?).
But nobody has thus far won the contest using any language involving
"Lots of Insipid Silly Parentheses."
And it is reasonable to expect that there would be some degree to which
the language would be considered responsible for making it easier for
the programmers to "do their thing." Nobody has won when writing
assembly language, after all...
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/lisp.html
"Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper..."
-- Kenny Tilton <····@liii.com>
Christopher Browne <········@acm.org> writes:
> Nobody has won when writing assembly language, after all...
Well...
Team TAL (http://www.cs.cornell.edu/talc/icfp99-contest/contest.htm)
did receive the special "Joker" prize at the ICFP'99 contest.
But noone has won with a serious entry in assembly language.
--
aleksey
Christopher Browne <········@acm.org> writes:
> A long time ago, in a galaxy far, far away, Nils Goesche <······@cartan.de> wrote:
>> ·········@gmx.net (thelifter) writes:
>>
>>> Did Lisp ever win this contest?
>>
>> It's not languages that win this contest, it's programmers.
>
> .. And to date, none of the winning programmers have been using Lisp.
As far as I can tell from the contest web site, last year was the
first year that anyone using Common Lisp even /entered/, so perhaps we
don't really have enough results yet to ascribe any real significance
to this?
Someone will correct me if I'm wrong, I am sure.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Christopher Browne wrote:
> A long time ago, in a galaxy far, far away, Nils Goesche
> <······@cartan.de> wrote:
>> ·········@gmx.net (thelifter) writes:
>>
>>> Did Lisp ever win this contest?
>>
>> It's not languages that win this contest, it's programmers.
>
> .. And to date, none of the winning programmers have been using Lisp.
>
> The nearest that it has come is if you squint at things sufficiently
> sideways to consider that Dylan might be considered "a Lisp," as a
> Dylan-based team got honorable mention (last year?).
>
> But nobody has thus far won the contest using any language involving
> "Lots of Insipid Silly Parentheses."
>
> And it is reasonable to expect that there would be some degree to which
> the language would be considered responsible for making it easier for
> the programmers to "do their thing." Nobody has won when writing
> assembly language, after all...
I personally think that with languages highlevel enough (like Lisp but of
course like ML or Dylan or Haskell or <add your favorite language> too) it
is mainly the programmers skills who decide if one wins or not.
Of the past few contests there were only Common Lisp participants in the
very last one. Some teams using languages like OCaml were lead by people
who actually designed the language themselves and have extensive wisdom
about the language and the implementation. The past contests have shown
that those teams who have some experience with the problem domain _and_ are
not hindered by a much too worse language tend to win.
The only thing one can conclude from that is that those languages who got
used by winning teams at least did not get in the way of those programmers.
You cannot conclude which language is actually better than the other.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> The only thing one can conclude from that is that those languages who got
> used by winning teams at least did not get in the way of those
> programmers. You cannot conclude which language is actually better than
> the other.
Oh, please! The contest results are clear and unambiguous:
"O'Caml/Haskell/Cilk is the programming tool of choice for discriminating
hackers"
Of course, it should be noted that the winning teams are usually large,
well-organized, with something to prove, while most, say, C/C++ entries are
small, casual, oftentimes single-person teams.
Cheers,
Oleg
P.S. IIRC There were plenty of Scheme entries in the contest
P.P.S. ML is often considered to be a distant Lisp discendant, so if you
squint really, really hard, O'Caml is a Lisp.
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
* oleg inconnu wrote:
> Oh, please! The contest results are clear and unambiguous:
> "O'Caml/Haskell/Cilk is the programming tool of choice for
> discriminating hackers"
Another view would be that these languages are used by people with
enough time on their hands to enter such competitions. How well that
correlates with real-world success I'm not sure.
--tim
Tim wrote:
> Another view would be that these languages are used by people with
> enough time on their hands to enter such competitions. How well that
> correlates with real-world success I'm not sure.
From what I can tell, the winners with OCaml were the people from the
research group who wrote OCaml! Is there such a consituency in c.l.l?
;)w
Will Deakin <···········@hotmail.com> writes:
> Tim wrote:
> > Another view would be that these languages are used by people with
> > enough time on their hands to enter such competitions. How well that
> > correlates with real-world success I'm not sure.
> From what I can tell, the winners with OCaml were the people from the
> research group who wrote OCaml! Is there such a consituency in c.l.l?
No. CL implementors are too busy implementing CL (or using it to
implement other things) to play many games.
:-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
> No. CL implementors are too busy implementing CL (or using it to
> implement other things) to play many games.
What's a game? Look at how much money big companies pay to back
sports teams. I would think Franz would benefit hugely from a CL win.
The general public tends to form stereotypes based on winning vs
losing, on being famous vs unknown, etc. Think of all the PHB's who
can be persuaded to use ACL if it can be shown to be a winner.
It seems to me the biggest disadvantage of competing is that you might
lose, and that could be counterproductive. But if you do it right, it
should be easy. Just get the whole Franz programming team together
for the contest, have them work on different algorithms to solve the
problem, compare the results, do lots of profiling and optimization,
use some assembler language for the most speed critical parts, etc.,
and you should win easily.
Centuries ago, Nostradamus foresaw when ··········@mailandnews.com (Software Scavenger) would write:
> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>
>> No. CL implementors are too busy implementing CL (or using it to
>> implement other things) to play many games.
>
> What's a game? Look at how much money big companies pay to back
> sports teams. I would think Franz would benefit hugely from a CL win.
> The general public tends to form stereotypes based on winning vs
> losing, on being famous vs unknown, etc. Think of all the PHB's who
> can be persuaded to use ACL if it can be shown to be a winner.
I'm not sure that it's necessarily going to be _that_ much of a
benefit, but we can imagine.
> It seems to me the biggest disadvantage of competing is that you
> might lose, and that could be counterproductive. But if you do it
> right, it should be easy. Just get the whole Franz programming team
> together for the contest, have them work on different algorithms to
> solve the problem, compare the results, do lots of profiling and
> optimization, use some assembler language for the most speed
> critical parts, etc., and you should win easily.
If "Team Franz" did _badly_, that would reflect badly on the company,
which would be downright counterproductive.
It might be appropriate to run a "strawman" competition in private to
ensure that it seems a reasonable thing to do. Maybe run a private
competition on a couple of past years' problems, and make sure that
the group appears competitive.
I think it _would_ be good advertising.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://cbbrowne.com/info/languages.html
"No, you misunderstand. Microsoft asked some hackers how they could
make their system secure - the hackers replied "Turn it off.". So they
did." -- Anthony Ord
··········@mailandnews.com (Software Scavenger) writes:
> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>
> > No. CL implementors are too busy implementing CL (or using it to
> > implement other things) to play many games.
>
> What's a game? Look at how much money big companies pay to back
> sports teams. I would think Franz would benefit hugely from a CL win.
I heard a news program yesterday, and the bottom line was that
the average yearly salary of a starting baseball player has jumped
only recently from 50K USD to 2 M USD, and is supposed to go up to
3 M this year, despite the potential for a players' strike.
I'd be happy to play the game if you were willing to front me that
kind of money. :-)
> The general public tends to form stereotypes based on winning vs
> losing, on being famous vs unknown, etc. Think of all the PHB's who
> can be persuaded to use ACL if it can be shown to be a winner.
PHB's? Do you mean PHD's, or is this yet another new cute TLA that
I don't know about?
I'm not personally into winning or losing here; I have enough work for
myself to take me though to the next 5 years at least, and that is
without any new projects coming up. I don't know about the other
Franz employees, but I'll probably pass.
> It seems to me the biggest disadvantage of competing is that you might
> lose, and that could be counterproductive. But if you do it right, it
> should be easy. Just get the whole Franz programming team together
> for the contest, have them work on different algorithms to solve the
> problem, compare the results, do lots of profiling and optimization,
> use some assembler language for the most speed critical parts, etc.,
> and you should win easily.
Others have already responded, but I'll say it as well: why don't you
enter it yourself? I don't know if Franz would commit the resources
to such a weekend contest (what's a weekend ? :-) but there is no
limit to the number of entries that can come from a language. And I
personally think that the results would be more impressive if the
winning entry were not from implementors, but normal, everyday users.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
The world rejoiced as Duane Rettig <·····@franz.com> wrote:
> ··········@mailandnews.com (Software Scavenger) writes:
>
>> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>>
>> > No. CL implementors are too busy implementing CL (or using it to
>> > implement other things) to play many games.
>>
>> What's a game? Look at how much money big companies pay to back
>> sports teams. I would think Franz would benefit hugely from a CL win.
>
> I heard a news program yesterday, and the bottom line was that
> the average yearly salary of a starting baseball player has jumped
> only recently from 50K USD to 2 M USD, and is supposed to go up to
> 3 M this year, despite the potential for a players' strike.
>
> I'd be happy to play the game if you were willing to front me that
> kind of money. :-)
>
>> The general public tends to form stereotypes based on winning vs
>> losing, on being famous vs unknown, etc. Think of all the PHB's who
>> can be persuaded to use ACL if it can be shown to be a winner.
>
> PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> I don't know about?
That's short for Pointy-Haired Managers. Oh dear, I think I
misspelled Manager...
> I'm not personally into winning or losing here; I have enough work
> for myself to take me though to the next 5 years at least, and that
> is without any new projects coming up. I don't know about the other
> Franz employees, but I'll probably pass.
>> It seems to me the biggest disadvantage of competing is that you
>> might lose, and that could be counterproductive. But if you do it
>> right, it should be easy. Just get the whole Franz programming
>> team together for the contest, have them work on different
>> algorithms to solve the problem, compare the results, do lots of
>> profiling and optimization, use some assembler language for the
>> most speed critical parts, etc., and you should win easily.
>
> Others have already responded, but I'll say it as well: why don't
> you enter it yourself? I don't know if Franz would commit the
> resources to such a weekend contest (what's a weekend ? :-) but
> there is no limit to the number of entries that can come from a
> language. And I personally think that the results would be more
> impressive if the winning entry were not from implementors, but
> normal, everyday users.
Ah, but if the Franz staff showed themselves to be Really Studly
Coders, this wouldn't _usually_ be considered a bad thing.
What has been happening is that various "language proponents" have
been fielding teams of what might be termed "ringers."
For instance, the main OCAML team has been made up of the implementors
of the language, and they surely _do_ have some advantage over their
opponents. Franz folk that have a long history of intimacy with CL
implementations would be expected to have similar advantage.
It won't make you rich, and if you don't _need_ good advertising, it's
not of value.
Indeed, if you're "too busy," and your present customers don't want
other people coming to use CL, then the exercise clearly _isn't_ of
value.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://cbbrowne.com/info/lsf.html
"CANADA: 132 years in the same location! Open to serve you 24 hours
per day, 7 days per week. Now with 3 Territories!"
* Christopher Browne wrote:
> Ah, but if the Franz staff showed themselves to be Really Studly
> Coders, this wouldn't _usually_ be considered a bad thing.
You have to look at the forum though. ICFP is, what, International
Conference on Functional Programming? There are probably less
fashionable things you could win, but they'll have names with the
letters A and I next to each other, or the terms `logic programming'
or `theoretical'. If you win competitions in the Functional Logic
Programming for Theoretical AI Conference then your best bet is to
hope no one notices. If you even *enter* them you'd better worry.
What you want to do instead is implement a transactional database in a
spare afternoon and demonstrate 15 times the tpmC performance of a
high-end HPaq machine when running on a ZX Spectrum. *That's* a
competition you want to win.
--tim
Christopher Browne <········@acm.org> writes:
> The world rejoiced as Duane Rettig <·····@franz.com> wrote:
> > ··········@mailandnews.com (Software Scavenger) writes:
> >
> >> The general public tends to form stereotypes based on winning vs
> >> losing, on being famous vs unknown, etc. Think of all the PHB's who
> >> can be persuaded to use ACL if it can be shown to be a winner.
> >
> > PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> > I don't know about?
>
> That's short for Pointy-Haired Managers. Oh dear, I think I
> misspelled Manager...
OK, I hereby renounce my position as Senior Nerd, and hereby hang
my head in shame.
> Ah, but if the Franz staff showed themselves to be Really Studly
> Coders, this wouldn't _usually_ be considered a bad thing.
Ah, but I already thought of myself as such an RSC, and now I
must eat my humble-pie and lose my god-like status.
...
> What has been happening is that various "language proponents" have
> been fielding teams of what might be termed "ringers."
>
> For instance, the main OCAML team has been made up of the implementors
> of the language, and they surely _do_ have some advantage over their
> opponents. Franz folk that have a long history of intimacy with CL
> implementations would be expected to have similar advantage.
But that's the beauty of CL; I truly don't believe that there would
be a similar advantage. If the problem domain is not itself CL,
and it's not just the fastest program that wins, then any competent
CL programmer should be able to do just as well as an implementor.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
> But that's the beauty of CL; I truly don't believe that there would
> be a similar advantage. If the problem domain is not itself CL,
> and it's not just the fastest program that wins, then any competent
> CL programmer should be able to do just as well as an implementor.
The advantage of the implementors would be more CL experience,
combined with all the reusable code they have accumulated over the
years. The more experience and reusable code you have, the more
likely some of it might apply to the problem domain of the contest.
And the implementors can afford to assemble a powerful team, which can
do some of the work in parallel.
A good way to practice would be to do the problems from previous
years' contests, and see how well your team does, before actually
entering the contest. But if you do that, you have to hurry, because
the contest is at the end of this month.
Deciding to enter this contest is not actually quite as simple a
decision as it seems. It's not just a game. The way the world works,
Franz is expected to enter and try to win, because of market
leadership etc. Each year Franz chooses not to enter, and the contest
grows bigger and more well known, Franz will more and more be
considered a loser by default for not entering the contest.
No matter how big a factor the speed of the program is, Franz can
solve that problem by simply rewriting as much of it as needed in
assembler language after using CL to prototype and compare different
ways to solve the problem. The time consuming part is coming up with
a solution, which is where CL shines. You could then translate the
whole thing to assembler language in a few hours if necessary.
> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>
> > But that's the beauty of CL; I truly don't believe that there would
> > be a similar advantage. If the problem domain is not itself CL,
> > and it's not just the fastest program that wins, then any competent
> > CL programmer should be able to do just as well as an implementor.
Agreed. Someone who's familiar with the compiler s/he's using would
be able to produce fast code with much less thinking about it, and
futzing with disassembly listings -- but I think all competant CL
coders who work in domains where performance counts are familiar
enough with their compiler that they're adapted to it, and their
coding style &/or utilities are in harmony with the compiler's strong
points. I could be wrong though, because I'm definately the type to
do this, and I might be assuming this impulse is more widespread than it is.
··········@mailandnews.com (Software Scavenger) writes:
> Deciding to enter this contest is not actually quite as simple a
> decision as it seems. It's not just a game. The way the world works,
> Franz is expected to enter and try to win, because of market
> leadership etc. Each year Franz chooses not to enter, and the contest
> grows bigger and more well known, Franz will more and more be
> considered a loser by default for not entering the contest.
I would agree with you if this were considered something that was
normal for a language vendor to do. But it's not, and I'm pretty sure
that 99% of Franz's customers will only notice them in relation to
this contest if they enter. If I were a Franz customer, I would be
happy that they weren't wasting the developer-hours on it. After all,
I'm sure that Duane (for example) has a limited number of all-weekend
coding binges in him. I'd be a lot happier if he spent them improving
the product, rather than playing marketing games.
> No matter how big a factor the speed of the program is, Franz can
> solve that problem by simply rewriting as much of it as needed in
> assembler language after using CL to prototype and compare different
> ways to solve the problem.
Now that *would* make me worry! One of CL's strong points is that it
allows you to give the compiler enough information to do aggressive
optimization -- and one of ACL's strong points is supposed to be its
compiler. In a 3-day competition, if I were using CMUCL, I would look
at disassembly listings for critical sections of code, and *possibly*
write an optimization or two, but I would expect to not have to
actually write assembly language myself. If the Franz team felt that
the ACL compiler couldn't do a good enough job of optimizing their
code, even knowing how to write code for it, I would have to seriously
reconsider my assumptions about its quality.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
>>>>> "Software" == Software Scavenger <··········@mailandnews.com> writes:
Software> Deciding to enter this contest is not actually quite as simple a
Software> decision as it seems. It's not just a game. The way the world works,
Software> Franz is expected to enter and try to win, because of market
Software> leadership etc. Each year Franz chooses not to enter, and the contest
Software> grows bigger and more well known, Franz will more and more be
Software> considered a loser by default for not entering the contest.
Franz is already well known. I think it would hurt more to lose for
whatever reason than not be there at all. Good teams lose all the
time to less capable teams all the time.
Ray
The world rejoiced as ··········@mailandnews.com (Software Scavenger) wrote:
> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>> But that's the beauty of CL; I truly don't believe that there would
>> be a similar advantage. If the problem domain is not itself CL,
>> and it's not just the fastest program that wins, then any competent
>> CL programmer should be able to do just as well as an implementor.
>
> The advantage of the implementors would be more CL experience,
> combined with all the reusable code they have accumulated over the
> years. The more experience and reusable code you have, the more
> likely some of it might apply to the problem domain of the contest.
> And the implementors can afford to assemble a powerful team, which can
> do some of the work in parallel.
>
> A good way to practice would be to do the problems from previous
> years' contests, and see how well your team does, before actually
> entering the contest. But if you do that, you have to hurry, because
> the contest is at the end of this month.
I wouldn't think that there would be time, at this point, unless they
had people that were _really_ serious about entering the contet.
> Deciding to enter this contest is not actually quite as simple a
> decision as it seems. It's not just a game. The way the world
> works, Franz is expected to enter and try to win, because of market
> leadership etc. Each year Franz chooses not to enter, and the
> contest grows bigger and more well known, Franz will more and more
> be considered a loser by default for not entering the contest.
Perhaps.
> No matter how big a factor the speed of the program is, Franz can
> solve that problem by simply rewriting as much of it as needed in
> assembler language after using CL to prototype and compare different
> ways to solve the problem. The time consuming part is coming up
> with a solution, which is where CL shines. You could then translate
> the whole thing to assembler language in a few hours if necessary.
I would *hope* that would be absolutely _wrong_.
If ACL is a decent, salable product, then its native optimizations
should be quite adequate for the vast majority of the resulting
application. Nobody needs to do hand-crafted assembler to write
output formatting routines, for instance.
If it's a _superb_ product, deserving of premium prices, then they
should seldom, if ever, _need_ to rewrite chunks of it expressly in
assembly language.
I think it would be an impressive result for the report to include
something along the lines of:
"... Once we got it working, we looked at some of the bottlenecks,
and found three places where the compiler was not generating ideal
object code. We created five functions written in assembler as a
result that sped the application up five-fold. It will lead to us
adding two optimizations to the compiler; the other three functions
represented quite unusual code that doesn't lead us to any compiler
improvements. The ease with which we added those functions is a
credit to the compiler environment..."
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://cbbrowne.com/info/sap.html
Signs of a Klingon Programmer - 19. "My program has just dumped Stova
Core!"
Christopher Browne <········@acm.org> writes:
> I think it would be an impressive result for the report to include
> something along the lines of:
>
> "... Once we got it working, we looked at some of the bottlenecks,
> and found three places where the compiler was not generating ideal
> object code. We created five functions written in assembler as a
> result that sped the application up five-fold. It will lead to us
> adding two optimizations to the compiler;
..."
Now _this_ it the first truly cogent argument for me being involved
in such a contest.
And now, not directly to you, Christopher:
All previous joking and toungue-in-cheek aside, and in fact,
ironically, the most significant disincentive for me being involved
with this contest has nothing to do with my employer; it is personal
and has to do with the timing of the contest: The contest is
(appropriately) scheduled for minimum disruption to a potential
entrant's work time, thus on a weekend. But futhermore, it is
scheduled on Labor Day weekend. And, contrary to my jokes in
previous articles, I do have a life, and a family. Is winning such
a contest of enough value to my Company to shed some develompment
time to work on this marketing project? Perhaps yes, perhaps no
(although since it is on a weekend it is not likely to cut much into
development time). Is winning such a contest of enough value to
shed a long weekend of time with my family? Absolutely not.
I'd like for people on this thread to simply get over whether or not
Franz employees participate in this contest. I may, or I may not.
Others of us may, or may not. Whether or not any of us participate
is a decision made by each individual, just as it is a decision made
by you to participate or not. And if you decide not to participate,
I will respect your decision not to participate, whatever the reason
for that decision is - with one exception: If you decide not to
participate because you figure that Franz people, or Xanalys people,
or Nils Goesche again, or Roger Corman, will do the job, then that
is not an acceptable reason; that is just a cop-out.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Software Scavenger <··········@mailandnews.com> wrote:
> Duane Rettig <·····@franz.com> wrote in message
> news:<·············@beta.franz.com>...
> > But that's the beauty of CL; I truly don't believe that there would
> > be a similar advantage. If the problem domain is not itself CL,
> > and it's not just the fastest program that wins, then any competent
> > CL programmer should be able to do just as well as an implementor.
> The advantage of the implementors would be more CL experience,
> combined with all the reusable code they have accumulated over the
> years. The more experience and reusable code you have, the more
> likely some of it might apply to the problem domain of the contest.
> And the implementors can afford to assemble a powerful team, which can
> do some of the work in parallel.
> A good way to practice would be to do the problems from previous
> years' contests, and see how well your team does, before actually
> entering the contest. But if you do that, you have to hurry, because
> the contest is at the end of this month.
> Deciding to enter this contest is not actually quite as simple a
> decision as it seems. It's not just a game. The way the world works,
> Franz is expected to enter and try to win, because of market
> leadership etc. Each year Franz chooses not to enter, and the contest
> grows bigger and more well known, Franz will more and more be
> considered a loser by default for not entering the contest.
Hmm. I think that this contest would need to be a great deal higher
profile than it is for this to be a serious issue.
When I see Haskell, OcaML and Dylan (or whatever languages are winning
ICFP in a few years) in as wide use as C++ or Java, then I'd say you
might have a point. As it is, It's not clear that those languages are
anymore popular than CL. I also like Paul Graham's take on Lisp. As
long as a language is popular enough to avoid any threat of becoming
moribund, it's a competitive advantage to have fewer people using it
(given that it's better than most of the competition).
Of course, this doesn't matter so much to Franz, but I know as a small
business owner, that not every company is designed to make billions and
serve the PHB's of the world. If you're getting all the work you want
and making plenty of money as it is, why specifically start selling to
people who can't really appreciate what you do?
And that's pretty much what Franz would be doing by trying to win a
whole pile of contests like this. I can't see why unless they're either
hurting for business or want to be the next <insert bloated software
megacorp producing inelegant crap here>.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
Michael Sullivan wrote:
> Hmm. I think that this contest would need to be a great deal higher
> profile than it is for this to be a serious issue.
>
> When I see Haskell, OcaML and Dylan (or whatever languages are winning
> ICFP in a few years) in as wide use as C++ or Java, then I'd say you
> might have a point. As it is, It's not clear that those languages are
> anymore popular than CL. I also like Paul Graham's take on Lisp. As
> long as a language is popular enough to avoid any threat of becoming
> moribund, it's a competitive advantage to have fewer people using it
> (given that it's better than most of the competition).
>
> Of course, this doesn't matter so much to Franz, but I know as a small
> business owner, that not every company is designed to make billions and
> serve the PHB's of the world. If you're getting all the work you want
> and making plenty of money as it is, why specifically start selling to
> people who can't really appreciate what you do?
>
> And that's pretty much what Franz would be doing by trying to win a
> whole pile of contests like this. I can't see why unless they're either
> hurting for business or want to be the next <insert bloated software
> megacorp producing inelegant crap here>.
According to Paul Graham, whom you were quoting, "most hackers are very
competitive" [1].
BTW, what bothers me about the contest announcement is that, this year, it
has not been posted to comp.lang.c and comp.lang.c++. I think I'll Cc: to
c.l.f in hopes that the original poster notices.
Oleg
[1] http://www.paulgraham.com/spam.html (grep hackers) BTW, I was surprised
to see a Lisper who gets statistical methods.
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
Oleg <············@myrealbox.com> wrote:
> Michael Sullivan wrote:
> > And that's pretty much what Franz would be doing by trying to win a
> > whole pile of contests like this. I can't see why unless they're either
> > hurting for business or want to be the next <insert bloated software
> > megacorp producing inelegant crap here>.
> According to Paul Graham, whom you were quoting, "most hackers are very
> competitive" [1].
Well, that's certainly true. I should make clear that I was only
responding to the suggestion that there was a significant *economic*
justification for CL implementors to put together teams for the ICFP
contests. Obviously, if you just think that doing a 72-hour programming
contest would be *fun* or make a point, that's certainly a good enough
reason to enter, whatever the commercial justification or lack thereof.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT ·······@bcect.com
Duane Rettig <·····@franz.com> writes:
> Christopher Browne <········@acm.org> writes:
>
> > The world rejoiced as Duane Rettig <·····@franz.com> wrote:
> > > ··········@mailandnews.com (Software Scavenger) writes:
> > >
> > >> The general public tends to form stereotypes based on winning vs
> > >> losing, on being famous vs unknown, etc. Think of all the PHB's who
> > >> can be persuaded to use ACL if it can be shown to be a winner.
> > >
> > > PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> > > I don't know about?
> >
> > That's short for Pointy-Haired Managers. Oh dear, I think I
> > misspelled Manager...
Pointy-Heared Boss
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
The name is Baud,...... James Baud.
Christopher Browne <········@acm.org> writes:
> Ah, but if the Franz staff showed themselves to be Really Studly
> Coders, this wouldn't _usually_ be considered a bad thing.
Finding out that Franz staff were Really Studly Coders wouldn't be
particularly shocking news to readers of this newsgroup, at least...
Cheers,
M.
--
Every now and then, Google doesn't throw up what I need so I start
checking Altavista, Yahoo, etc. In almost every single case, I am
brutally reminded why I use Google in the first place.
-- John Riddoch, asr
A long time ago, in a galaxy far, far away, Michael Hudson <···@python.net> wrote:
> Christopher Browne <········@acm.org> writes:
>
>> Ah, but if the Franz staff showed themselves to be Really Studly
>> Coders, this wouldn't _usually_ be considered a bad thing.
>
> Finding out that Franz staff were Really Studly Coders wouldn't be
> particularly shocking news to readers of this newsgroup, at least...
We're not the ones that need convincing of that.
--
(reverse (concatenate 'string ·············@" "sirhc"))
http://cbbrowne.com/info/linux.html
Signs of a Klingon Programmer #3: "By filing this TPR you have
challenged the honor of my family. Prepare to die!"
In article <··············@pc150.maths.bris.ac.uk>,
Michael Hudson <···@python.net> wrote:
> Christopher Browne <········@acm.org> writes:
>
> > Ah, but if the Franz staff showed themselves to be Really Studly
> > Coders, this wouldn't _usually_ be considered a bad thing.
>
> Finding out that Franz staff were Really Studly Coders wouldn't be
> particularly shocking news to readers of this newsgroup, at least...
That's not who you need to convince that CL is a viable language.
I know it says "Functional Programming" if you expand out the acronym,
but even so the contest has been getting pretty wide coverage the last
couple of years, including from the SlashDot crowd, the results being
written up in Dr Dobbs etc.
-- Bruce
Duane Rettig <·····@franz.com> writes:
> PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> I don't know about?
http://www.tuxedo.org/~esr/jargon/html/entry/PHB.html
Where do you live? <g>
--
Eduardo Mu�oz
"Eduardo Mu�oz" <···@jet.es> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> > I don't know about?
>
> http://www.tuxedo.org/~esr/jargon/html/entry/PHB.html
>
> Where do you live? <g>
It's pretty embarrassing; I live only a mile or two from
where Scott Adams used to work at Pac Bell :-(
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
> "Eduardo Mu�oz" <···@jet.es> writes:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > PHB's? Do you mean PHD's, or is this yet another new cute TLA that
> > > I don't know about?
> >
> > http://www.tuxedo.org/~esr/jargon/html/entry/PHB.html
> >
> > Where do you live? <g>
>
> It's pretty embarrassing; I live only a mile or two from
> where Scott Adams used to work at Pac Bell :-(
Never be caught again! Impress your friends!!
http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=phb&Find=Find
(of course you will still need to consider the context...)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
··········@mailandnews.com (Software Scavenger) writes:
> Duane Rettig <·····@franz.com> wrote in message news:<·············@beta.franz.com>...
>
> > No. CL implementors are too busy implementing CL (or using it to
> > implement other things) to play many games.
>
> What's a game? Look at how much money big companies pay to back
> sports teams. I would think Franz would benefit hugely from a CL win.
> The general public tends to form stereotypes based on winning vs
> losing, on being famous vs unknown, etc. Think of all the PHB's who
> can be persuaded to use ACL if it can be shown to be a winner.
>
> It seems to me the biggest disadvantage of competing is that you might
> lose, and that could be counterproductive. But if you do it right, it
> should be easy. Just get the whole Franz programming team together
> for the contest, have them work on different algorithms to solve the
> problem, compare the results, do lots of profiling and optimization,
> use some assembler language for the most speed critical parts, etc.,
> and you should win easily.
Why don't you participate yourself? I submitted an entry (team watt)
last year and to my own surprise made it to place 37 of 263 or
something, even though I had only recently returned to CL and
forgotten pretty much everything so I spent most of the time reading
CLTL instead of coding anything (I couldn't navigate the HyperSpec as
quickly as today at the time). Don't talk, don't demand, just do :-)
It's really fun, I'll try again this year, hopefully with better
results, but I can't guarantee anything ;-) I'll work alone for two
reasons -- if I really don't like the problem description, I'll just
enjoy the two days I took off from work doing something more
interesting. You can't do that if you have a team waiting for you.
And I have this image in my head of a group of Lispers discussing for
three days what the most ideal design would be instead of writing
anything ;-) Remember: It's not a beauty contest.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
* Nils Goesche
| And I have this image in my head of a group of Lispers discussing for three
| days what the most ideal design would be instead of writing anything ;-)
That would be Schemers.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * oleg inconnu wrote:
> > Oh, please! The contest results are clear and unambiguous:
> > "O'Caml/Haskell/Cilk is the programming tool of choice for
> > discriminating hackers"
>
> Another view would be that these languages are used by people with
> enough time on their hands to enter such competitions. How well that
> correlates with real-world success I'm not sure.
The ICFP contest walks a fine line between using problems that are too
trivial to be meaningfull on the one hand and contest durations too long
for people with a real job on the other.
Personally I think that making the contest 72 hours, including a
weekend, is a pretty good compromise. You only need to take one day off
work in order to compete fully, and even without that you may be able to
do a pretty good job in the 64 hours of a standard weekend :-)
-- Bruce
In article <············@newsmaster.cc.columbia.edu>, Oleg wrote:
> Jochen Schmidt wrote:
>
>> The only thing one can conclude from that is that those languages who got
>> used by winning teams at least did not get in the way of those
>> programmers. You cannot conclude which language is actually better than
>> the other.
>
> Oh, please! The contest results are clear and unambiguous:
> "O'Caml/Haskell/Cilk is the programming tool of choice for discriminating
> hackers"
While we are on the topic of citing useless data points that
don't prove anything, how about this:
I once tried to use a utility that was written in OCAML. The job was to
translate one markup language to another. I installed the compiler just to run
this program. I gave up on it, because it simply didn't work, handling only a
useless subset of the source language. I switched back to a perl program which
could do it. Naive me, I hoped that the OCAML job would be faster, cleaner, and
more robust and thorough than the really ugly Perl hack.
> Of course, it should be noted that the winning teams are usually large,
> well-organized, with something to prove, while most, say, C/C++ entries are
> small, casual, oftentimes single-person teams.
What kinds of considerations are factors in this contest? That is, other than
the requirement that the program run fast, and be delivered on time?
To what extent does the contest measure, for instance, a programming
team's resilience in the face of changing requirements? A realistic
contest would change the problem substantially two or three times.
Does the development of reusable code get any points?
How about error recovery, fault tolerance, robustness, and
all that stuff?
What about exploratory programming in the face of unclear requirements,
to get a better understanding of what is needed in the first place?
When the statement of the programming problem is relatively precise, or at
least when the nature of the solution is clearly characterized, when the
requirements don't change during the contest, and when the fastest running
solution wins, the contest strongly favors statically typed high-level
languages. Under the circumstances, the loss of flexibility doesn't hurt that
much, and the static typing provides a performance advantage.
Kaz Kylheku <···@ashi.footprints.net> writes:
> What kinds of considerations are factors in this contest? That is,
> other than the requirement that the program run fast, and be
> delivered on time?
If you Google a bit, you'll find all the information from previous
years.
But in short, the priorities are usually
1) timely delivery (but you can submit repeatedly, so there's
no reason to wait till the last minute if you got something
working)
2) Correctness
3) Speed/efficiency
What constitutes or does not constitute a "realistic test" is IMO a
philosophic question with no ready answer, but I think the contest
have had a fairly broad horizon, given the 72H limitation. (Feel free
to disagree!)
My impression is that the winners win because they have the best team,
rather than because they use the best tools. But on the other hand,
if they're the best teams, you don't expect them to choose poor tools,
do you? So I think the "programming tool of choice" hits the nail on
the head :-)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
In article <··············@sefirot.ii.uib.no>,
"Ketil Malde" <······@ii.uib.no> wrote:
> My impression is that the winners win because they have the best team,
> rather than because they use the best tools. But on the other hand,
> if they're the best teams, you don't expect them to choose poor tools,
> do you? So I think the "programming tool of choice" hits the nail on
> the head :-)
It's hard to argue with that.
With respect to team size:
The ray tracer in 2000 favoured big teams, because it was just *so* much
work to get it going at all. The organisers obviously knew that in
advance, because that's the only year that there wasn't a "lightning"
division for entries submitted within the first 24 hours.
Last year the winning team had just two people. The second place team
had two full timers and two part timers as was located in three
different countries (2 in NZ, 1 in USA, 1 in Germany), communicating via
IRC and CVS.
-- Bruce
In article <············@luna.vcn.bc.ca>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
> What kinds of considerations are factors in this contest? That is,
> other than the requirement that the program run fast, and be
> delivered on time?
>
> To what extent does the contest measure, for instance, a programming
> team's resilience in the face of changing requirements? A realistic
> contest would change the problem substantially two or three times.
>
> Does the development of reusable code get any points?
>
> How about error recovery, fault tolerance, robustness, and all that
> stuff?
>
> What about exploratory programming in the face of unclear
> requirements, to get a better understanding of what is needed in the
> first place?
>
> When the statement of the programming problem is relatively precise,
> or at least when the nature of the solution is clearly characterized,
> when the requirements don't change during the contest, and when the
> fastest running solution wins, the contest strongly favors statically
> typed high-level languages. Under the circumstances, the loss of
> flexibility doesn't hurt that much, and the static typing provides a
> performance advantage.
Perhaps you should go and read a few of the contest reports.
The 2000 contest task went through 18 versions during the contest. The
2001 task went though six revisions.
The programs have historically been subjected to an elimination round in
which all sorts of strange inputs were presented to them. Any failures
of any nature and they were out of the contest.
I wouldn't say that the nature of the solution has been "clearly
characterized" in any recent contest. The 1999 contest actively tried
to disguise the true nature of the task (or, should I say, the field
from which it was inspired). The 2001 contest had a theoretical optimal
solution which some of the contestents clearly knew (I didn't), but any
program that simply implemented that optimal solution would have been
far too slow to win. Original algorithm development was a requirement
in order to do well.
My experience from entering the last two contests is that it was hugely
valuable to have the exploratory/dynamic aspects of Dylan while figuring
out what was going to work at all. Different people work differently,
but I'm sure *I* couldn't have done nearly as well in the limited time
using SML or O'Caml or Haskell (or C or C++). In both contests I've
entered, I found Dylan hugely useful in being able to quickly prototype
some aspects of the program, get a working version to other team members
to build upon, and then go back and tweak the implementation (data
representation, algorithm, type declarations) to get a far faster
version with the same API.
-- Bruce
Bruce Hoult wrote:
> My experience from entering the last two contests is that it was hugely
> valuable to have the exploratory/dynamic aspects of Dylan while figuring
> out what was going to work at all. Different people work differently,
> but I'm sure *I* couldn't have done nearly as well in the limited time
> using SML or O'Caml or Haskell (or C or C++). In both contests I've
> entered, I found Dylan hugely useful in being able to quickly prototype
> some aspects of the program, get a working version to other team members
> to build upon, and then go back and tweak the implementation (data
> representation, algorithm, type declarations) to get a far faster
> version with the same API.
O'Caml has abstract data types and, of course, ways to specify the API. If
you were to write your program in O'Caml, edit the *.mli, give the initial
version to your team members, and then work on improving the implementation
while maintaining the same *.mli (API), what would be different compared to
Dylan [1]?
As to exploratory programming, in O'Caml, I usually stick all project
object files into a custom toplevel, so I can test the routines
interactively (In C++, I would write test drivers instead). How is
"exploratory programming" in Lisp/Dylan different from custom toplevels or
the interpreter in O'Caml?
Regards,
Oleg
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
In article <············@newsmaster.cc.columbia.edu>,
Oleg <············@myrealbox.com> wrote:
> Bruce Hoult wrote:
>
> O'Caml has abstract data types and, of course, ways to specify the API. If
> you were to write your program in O'Caml, edit the *.mli, give the initial
> version to your team members, and then work on improving the implementation
> while maintaining the same *.mli (API), what would be different compared to
> Dylan [1]?
Something that proved very useful last year was that Dylan doesn't
distinguish between (to use C terminology) accessing a field in a record
and calling a one-argument function. So there was a particular data
structure (describing the attributes of a run of text) that started life
as a heap-based object with a number of fields, some of which were
boolean, some of which were small integers, and some of which were
symbols choosen from a small set.
When allocating and manipulating this structure proved to be a critical
performance bottleneck I was able to reimplement it as a packed 32 bit
integer that was passed around by value, with inlined functions doing
the packing and unpacking of various fields. Despite this large change,
no change at all was required in client source code.
-- Bruce
Kaz Kylheku wrote:
> What kinds of considerations are factors in this contest? That is,
> other than the requirement that the program run fast, and be
> delivered on time?
>
> To what extent does the contest measure, for instance, a programming
> team's resilience in the face of changing requirements? A realistic
> contest would change the problem substantially two or three times.
Large (as answered by others).
> Does the development of reusable code get any points?
No.
It's difficult to measure this in a contest. I do have an idea that a
future contest could build upon the programs submitted in a previous
contest, points being awarded to the original teams if their software
was chosen often and successfully - but there are lots of small problems
lurking on that road.
> How about error recovery, fault tolerance, robustness, and
> all that stuff?
ICFP contests tend to explore borderline conditions, so robustness is
exercized to some degree. Of course, the judges don't have infinite
time, so it's still not an exhaustive test.
> What about exploratory programming in the face of unclear
> requirements, to get a better understanding of what is needed
> in the first place?
There's no customer to speak to, so prototyping and such stuff cannot be
tested.
Realistically, this is more a property of the development environment
than that of the language proper (of course, there are interactions, and
properties of common IDEs are a topic of interest - but a single contest
cannot test all aspects of programming).
Regards,
Joachim
--
This is not an official statement from my employer.
Joachim Durchholz <·················@munich.netsurf.de> writes:
>Kaz Kylheku wrote:
>
> > What about exploratory programming in the face of unclear
> > requirements, to get a better understanding of what is needed
> > in the first place?
>
>There's no customer to speak to, so prototyping and such stuff cannot be
>tested.
I thought the ability to produce a working prototype in less than three
days was exactly what the contest was testing!
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson wrote:
> Joachim Durchholz <·················@munich.netsurf.de> writes:
>>There's no customer to speak to, so prototyping and such stuff cannot be
>>tested.
>
> I thought the ability to produce a working prototype in less than three
> days was exactly what the contest was testing!
Yes, but it's missing the "customer feedback" part of rapid prototyping.
(Not sure which side of the argument this supports though...)
Regards,
Joachim
--
This is not an official statement from my employer.
From: George Russell
Subject: Re: ICFP 2002 Programming Contest
Date:
Message-ID: <3D64FD43.E1180B0F@tzi.de>
An aside:
One thing I found most interesting and encouraging about last year's contest was that both
winners (of the Lightning division, and of the contest overall) won by coming up with clever
algorithms which apparently came from completely unrelated areas. The actual problem was
optimising an XML-like language. IIRC, the lightning entry used an algorithm designed to
minimise page faults, and the outright winner used an algorithm designed to parse context-free
grammars.
I heard a rumour that the outright winners thought they could probably have won using C (rather
than Haskell); from the little I know of their approach this seems reasonable. But since the
programming contest does not emphasise CPU time that much, you might as well use something like
Haskell since it's much more important to be able to prototype complex algorithms quickly than
squeeze out the last clock-cycle of performance.
All the same it would be really amusing if one day the ICFP judges were forced to pronounce
"C/PLI/FORTRAN is the programming tool of choice for discriminating hackers". Is the contest
announced on groups like comp.lang.misc and specific relevant newsgroups (for example
comp.graphics if the problem is a graphical one)?
In article <·················@tzi.de>, George Russell <···@tzi.de>
wrote:
> All the same it would be really amusing if one day the ICFP judges
> were forced to pronounce "C/PLI/FORTRAN is the programming tool of
> choice for discriminating hackers".
The first contest (1998) was won by a program written in Cilk, which is
C with facilities for parallel processing.
http://www.ai.mit.edu/extra/icfp-contest/winners.html
Last year, it looked from the preliminary results as if a program
written in C++ was the strongest, but later rounds of tests exposed a
bug.
You can certainly write programs in C that could win the ICFP contest.
The question is whether you could write and debug them quickly enough.
-- Bruce
Bruce Hoult wrote:
>
> Last year, it looked from the preliminary results as if a program
> written in C++ was the strongest, but later rounds of tests exposed a
> bug.
Did they specifically look for bugs in the program, or was the test set
predetermined before the contest began?
Cheers
Oleg
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
Oleg <············@myrealbox.com> writes:
> Bruce Hoult wrote:
>> Last year, it looked from the preliminary results as if a program
>> written in C++ was the strongest, but later rounds of tests exposed a
>> bug.
> Did they specifically look for bugs in the program, or was the test set
> predetermined before the contest began?
As far as I understand, the judges don't inspect code to find bugs.
On the other hand, the complete test set is not known to developers in
advance.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde wrote:
> As far as I understand, the judges don't inspect code to find bugs.
> On the other hand, the complete test set is not known to developers in
> advance.
Yes, but is the whole test procedure predefined, or do they basically
change the rules during the game?
Oleg
--
"It's because they're stupid, that's why. That's why
everybody does everything." -- Homer Simpson.
Oleg wrote:
>
> Yes, but is the whole test procedure predefined, or do they basically
> change the rules during the game?
Not sure at what contest this happened - but at least once, the judges
had several programs that were too close for declaring a winner, so they
threw increasingly nasty test cases at the candidates until enough of
them dropped out (or showed bad performance).
That's nasty, but it still proves a point about functional programming
(only imperative programs were culled at that stage).
BTW I find it ironic that current Java advice is to avoid in-place
modification if possible :-)
Regards,
Joachim
--
This is not an official statement from my employer.
In article <················@gmx.de>, ·················@gmx.de wrote:
> BTW I find it ironic that current Java advice is to avoid in-place
> modification if possible :-)
Have you got a reference to this advice somewhere?
Lyndon While wrote:
> In article <················@gmx.de>, ·················@gmx.de wrote:
>
>>BTW I find it ironic that current Java advice is to avoid in-place
>>modification if possible :-)
>
> Have you got a reference to this advice somewhere?
Unfortunately, no.
Regards,
Joachim
--
This is not an official statement from my employer.
Oleg <············@myrealbox.com> writes:
> Bruce Hoult wrote:
>
> >
> > Last year, it looked from the preliminary results as if a program
> > written in C++ was the strongest, but later rounds of tests exposed a
> > bug.
>
> Did they specifically look for bugs in the program, or was the test set
> predetermined before the contest began?
http://slashdot.org/comments.pl?sid=21392&cid=2263345
--
···········@pulsesoft.com
In article <············@newsmaster.cc.columbia.edu>,
Oleg <············@myrealbox.com> wrote:
> Bruce Hoult wrote:
>
> >
> > Last year, it looked from the preliminary results as if a program
> > written in C++ was the strongest, but later rounds of tests exposed a
> > bug.
>
> Did they specifically look for bugs in the program, or was the test set
> predetermined before the contest began?
The two years I've been competing (and 1999 as well) the judges have
certainly thrown all sorts of borderline and strange input at the
programs in an effort to only keep correct programs in later judging
rounds. I suspect they tune the sample inputs depending on how things
are going, but I wouldn't expect them to read the source code -- which
you don't have to submit, anyway.
-- Bruce
"George Russell" <···@tzi.de> wrote in message ······················@tzi.de...
>
> All the same it would be really amusing if one day the ICFP judges
> were forced to pronounce "C/PLI/FORTRAN is the programming tool
> of choice for discriminating hackers".
I'd rather see INTERCAL win.
"Joe Marshall" <·············@attbi.com> writes:
> "George Russell" <···@tzi.de> wrote in message ······················@tzi.de...
> > All the same it would be really amusing if one day the ICFP judges
> > were forced to pronounce "C/PLI/FORTRAN is the programming tool
> > of choice for discriminating hackers".
>
> I'd rather see INTERCAL win.
Have they finished the floating-point library yet? I won't even ask if
it's IEEE-conforming.
And people think Scheme is backward because it lacks a module system. Sheesh!
david rush
--
A desire to adore a head of state is a grim transgression against
republicanism.
-- P. J. O'Rourke
George Russell wrote:
>
> An aside:
> I heard a rumour that the outright winners thought they could probably have won using C (rather
> than Haskell); from the little I know of their approach this seems reasonable. But since the
> programming contest does not emphasise CPU time that much, you might as well use something like
> Haskell since it's much more important to be able to prototype complex algorithms quickly than
> squeeze out the last clock-cycle of performance.
I think a group writing in C got an honorable mention at least.
Oleg <············@myrealbox.com> writes:
> Jochen Schmidt wrote:
>
> > The only thing one can conclude from that is that those languages who got
> > used by winning teams at least did not get in the way of those
> > programmers. You cannot conclude which language is actually better than
> > the other.
>
> Oh, please! The contest results are clear and unambiguous:
> "O'Caml/Haskell/Cilk is the programming tool of choice for discriminating
> hackers"
>
> Of course, it should be noted that the winning teams are usually large,
> well-organized, with something to prove, while most, say, C/C++ entries are
> small, casual, oftentimes single-person teams.
It is possible/realistic for a single-person team to win?
Did once a team use the language (please apologize me) TCL/Tk?
Christoph
In article <············@rznews2.rrze.uni-erlangen.de>,
Jochen Schmidt <···@dataheaven.de> wrote:
> > And it is reasonable to expect that there would be some degree to which
> > the language would be considered responsible for making it easier for
> > the programmers to "do their thing." Nobody has won when writing
> > assembly language, after all...
>
> I personally think that with languages highlevel enough (like Lisp but of
> course like ML or Dylan or Haskell or <add your favorite language> too) it
> is mainly the programmers skills who decide if one wins or not.
A high level language certainly makes it easier to get a *working* and
sufficiently correct program within the time allowed. That gets you
past the elimination round. But then in order to win the contest
against all those other smart people with expressive languages you need
to be able to make your correct program *fast*. I don't think you're
ever going to see an interpreted program take out a prize, no matter how
high level the language or clever the programmers.
> The past contests have shown that those teams who have some
> experience with the problem domain _and_ are not hindered by a much
> too worse language tend to win.
I've only done the contest twice, but my experience is that there is
time to learn the problem domain. To my shame I'd never even *heard* of
the term "dynamic programming" before last year's contest -- and didn't
use it in my optimizer -- but still managed to do pretty well with an
off-the-cuff algorithm and brute force.
> The only thing one can conclude from that is that those languages who got
> used by winning teams at least did not get in the way of those programmers.
> You cannot conclude which language is actually better than the other.
I agree with this. I'm perfectly happy to say that the ICFP contest
didn't prove which is the best of the winning languages such as OCaml or
Haskell or Dylan or Erlang. What it does show is that *any* of them
would be a huge improvement over C or C++ or Java or Perl in terms of
not getting in your way and allowing you create programs that are fast
to execute AND fast to write.
-- Bruce
Christopher Browne <········@acm.org> writes:
> The nearest that it has come is if you squint at things sufficiently
> sideways to consider that Dylan might be considered "a Lisp," as a
> Dylan-based team got honorable mention (last year?).
Yes, it was last year and the Dylan team came 2nd. See:
http://www.hoult.org/~bruce/dylan-hackers.html
Chris.
Nils Goesche <······@cartan.de> writes:
> It's not languages that win this contest, it's programmers.
>
> Regards,
Maybe we could collect some money to pay one or even some of our best
(commercially-minded) horses to win the contest for Lisp? Of course,
several questions arise:
1. Is there an easy way without much fees for paying say 10-50$ to
someone somewhere else in the world (say Norway) if this someone is
taking part in the contest? (Sometime ago, I heard something about
cyberbucks. What is the state of the art in easy money transfer?)
2. Would this paid participation be considered fair?
Nicolas.