* 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.
> > 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.
>> > 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 "gro.gultn@" "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.
Christopher Browne <cbbro...@acm.org> writes: > The world rejoiced as Duane Rettig <du...@franz.com> wrote: > > cubicle...@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.
Christopher Browne <cbbro...@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
> > 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.
> 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.
>> 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 "moc.enworbbc@" "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!"
Joachim Durchholz <joachim.durchh...@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 <f...@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.
Duane Rettig <du...@franz.com> wrote in message <news:4eld2ux9o.fsf@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.
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.
> > 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.
cubicle...@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! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> Duane Rettig <du...@franz.com> wrote in message <news:4eld2ux9o.fsf@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 "gro.mca@" "enworbbc")) http://cbbrowne.com/info/sap.html Signs of a Klingon Programmer - 19. "My program has just dumped Stova Core!"
Fergus Henderson wrote: > Joachim Durchholz <joachim.durchh...@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.
Christopher Browne <cbbro...@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 <du...@franz.com> writes: > Christopher Browne <cbbro...@acm.org> writes:
> > The world rejoiced as Duane Rettig <du...@franz.com> wrote: > > > cubicle...@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.
Software Scavenger <cubicle...@mailandnews.com> wrote: > Duane Rettig <du...@franz.com> wrote in message > <news:4eld2ux9o.fsf@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 mich...@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 <oleg_inco...@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 mich...@bcect.com
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 <3D64FD43.E1180...@tzi.de>, George Russell <g...@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.
