The above subject line makes people cringe at the thought of the ensuing flame wars. But why should it? It seems to me that when there is so much tension between opposing ideas, a good healthy shootout is sometimes the best way to clear the air.
Therefore, instead of endlessly arguing, getting emotional, falling into habits of ad hominem arguments, attacking language communities instead of language differences, etc., why don't we just have a genuine shootout, and get the whole thing over with fast?
The way this shootout could work, each "shot" consists of posting some code comparing the two languages or showing how one of them is elegant, or even just showing how easy it is to write a particular function in your favorite language. When the "enemy" shoots back, it could be with a counterexample, showing how their version of the same program in their language is even better than yours.
The programs should be simple enough to only be a few dozen lines of code at most. E.g. programs to convert between integers and Roman numerals, programs to find prime factors, etc. Nothing GUI, nothing FFI, nothing requiring in-depth knowledge of a particular implementation. Just simple programs that show the two languages in short snippets which can be easily compared.
cubicle...@mailandnews.com (Software Scavenger) writes: > The above subject line makes people cringe at the thought of the > ensuing flame wars. But why should it? It seems to me that when > there is so much tension between opposing ideas, a good healthy > shootout is sometimes the best way to clear the air.
> Therefore, instead of endlessly arguing, getting emotional, falling > into habits of ad hominem arguments, attacking language communities > instead of language differences, etc., why don't we just have a > genuine shootout, and get the whole thing over with fast?
> The way this shootout could work, each "shot" consists of posting some > code comparing the two languages or showing how one of them is > elegant, or even just showing how easy it is to write a particular > function in your favorite language. When the "enemy" shoots back, it > could be with a counterexample, showing how their version of the same > program in their language is even better than yours.
> The programs should be simple enough to only be a few dozen lines of > code at most. E.g. programs to convert between integers and Roman > numerals, programs to find prime factors, etc. Nothing GUI, nothing > FFI, nothing requiring in-depth knowledge of a particular > implementation. Just simple programs that show the two languages in > short snippets which can be easily compared.
Please include the whole multidimensional array library (or a pointer to the full blown implementation) in your Scheme reply :)
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
Software Scavenger wrote: > The above subject line makes people cringe at the thought of the > ensuing flame wars. But why should it? It seems to me that when > there is so much tension between opposing ideas, a good healthy > shootout is sometimes the best way to clear the air.
> Therefore, instead of endlessly arguing, getting emotional, falling > into habits of ad hominem arguments, attacking language communities > instead of language differences, etc., why don't we just have a > genuine shootout, and get the whole thing over with fast?
> The way this shootout could work, each "shot" consists of posting some > code comparing the two languages or showing how one of them is > elegant, or even just showing how easy it is to write a particular > function in your favorite language. When the "enemy" shoots back, it > could be with a counterexample, showing how their version of the same > program in their language is even better than yours.
> The programs should be simple enough to only be a few dozen lines of > code at most. E.g. programs to convert between integers and Roman > numerals, programs to find prime factors, etc. Nothing GUI, nothing > FFI, nothing requiring in-depth knowledge of a particular > implementation. Just simple programs that show the two languages in > short snippets which can be easily compared.
[ comp.lang.scheme removed from the list of newsgroups ]
Rolf Wester <rolf.wes...@t-online.de> writes: > Is there anything in Scheme that is comparable to the CL loop macro?
No. And judging from
CL-USER 157 > (loop for x being the external-symbols of :cl count x) 978
there is a whole lot of other questions like this, all having the answer ``No.''.
> Software Scavenger wrote:
> > The above subject line makes people cringe at the thought of the > > ensuing flame wars. But why should it? It seems to me that when > > there is so much tension between opposing ideas, a good healthy > > shootout is sometimes the best way to clear the air.
Only if there is some common ground for communication. There isn't in this case. How do you communicate with someone who believes ludicrous nonsense like ``If it can be derived, it doesn't belong into the spec.''?
> > Therefore, instead of endlessly arguing, getting emotional, falling > > into habits of ad hominem arguments, attacking language communities > > instead of language differences, etc., why don't we just have a > > genuine shootout, and get the whole thing over with fast?
Because it will never be over. The Schemers turned their backs to Lisp almost 20 years ago, and you won't bring them back with a little flame war.
> > The way this shootout could work, each "shot" consists of posting some > > code comparing the two languages or showing how one of them is > > elegant, or even just showing how easy it is to write a particular > > function in your favorite language. When the "enemy" shoots back, it > > could be with a counterexample, showing how their version of the same > > program in their language is even better than yours.
> > The programs should be simple enough to only be a few dozen lines of > > code at most. E.g. programs to convert between integers and Roman > > numerals, programs to find prime factors, etc. Nothing GUI, nothing > > FFI, nothing requiring in-depth knowledge of a particular > > implementation. Just simple programs that show the two languages in > > short snippets which can be easily compared.
I think you are overestimating the value of such little snippets. They don't tell you much. And we'll never agree on which snippet is more elegant than the other. Imagine the line noise some Perl H@X0R would contribute... you won't convince him either that your snippets are better.
And all that wouldn't even be a problem, if all Schemers had the decency of confining themselves to practicing their innocuous little habit in their support group comp.lang.scheme. But unfortunately, some of them feel the perverted, exhibitionist urge to constantly demonstrate their impediment to the rest of the world, like ``See? I really believe that. Please tell me how sick and filthy I am!'' The same goes for Dylan.
And vice versa, Lispers shouldn't unnecessarily bother them by posting intimidating code to comp.lang.scheme thus even /inviting/ their trolls and nutjobs to comp.lang.lisp.
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
cubicle...@mailandnews.com (Software Scavenger) wrote in message <news:a6789134.0208042138.75167e34@posting.google.com>... > The above subject line makes people cringe at the thought of the > ensuing flame wars. But why should it? It seems to me that when > there is so much tension between opposing ideas, a good healthy > shootout is sometimes the best way to clear the air.
> Therefore, instead of endlessly arguing, getting emotional, falling > into habits of ad hominem arguments, attacking language communities > instead of language differences, etc., why don't we just have a > genuine shootout, and get the whole thing over with fast?
[...]
The problem is that many many things that are part of Common Lisp either don't exist in Scheme or are part of 3rd-party libraries. Just to mention one example: hash tables. So it's very easy to write Common Lisp code that takes only a few lines, but would take hundreds of lines to duplicate in Scheme.
In other words, the 2 languages serve different domains; they have different design goals.
>>>>> "NG" == Nils Goesche <car...@cartan.de> writes:
NG> [ comp.lang.scheme removed from the list of newsgroups ]
>> Software Scavenger wrote: >> >> > The above subject line makes people cringe at the thought of the >> > ensuing flame wars. But why should it? It seems to me that when >> > there is so much tension between opposing ideas, a good healthy >> > shootout is sometimes the best way to clear the air.
NG> Only if there is some common ground for communication. There isn't NG> in this case.
That I agree with.
NG> How do you communicate with someone who believes ludicrous nonsense NG> like ``If it can be derived, it doesn't belong into the spec.''?
I know how you feel. I said that statement in response to what I considered was just as ludicrous a comment. I wasn't even saying that Scheme is right in following this kind of design paradigm, just that, Scheme does.
In fact, all I was just trying to do was to make sure that misinformation about Scheme wasn't spreading (that you can't do OO in native Scheme), and instead ended up in a flame war. Yikes. I didn't even try to claim that Scheme was better...just that it was different.
So we agree, we just weren't meant to communicate :-)
>> > Therefore, instead of endlessly arguing, getting emotional, falling >> > into habits of ad hominem arguments, attacking language communities >> > instead of language differences, etc., why don't we just have a >> > genuine shootout, and get the whole thing over with fast?
NG> Because it will never be over. The Schemers turned their backs to NG> Lisp almost 20 years ago, and you won't bring them back with a NG> little flame war.
Apparently. And any attempt to have a sane discussion seems to turn into a flame war so easily. Again, referring to the statement I made above -- I wasn't trying to claim that Scheme was better than Lisp, just different. And yet, the group interpreted it as a call to war.
>> > Just simple programs that show the two languages in short snippets >> > which can be easily compared.
NG> I think you are overestimating the value of such little snippets. NG> They don't tell you much. And we'll never agree on which snippet NG> is more elegant than the other. Imagine the line noise some Perl NG> H@X0R would contribute... you won't convince him either that your NG> snippets are better.
Exactly.
NG> And all that wouldn't even be a problem, if all Schemers had the NG> decency of confining themselves to practicing their innocuous NG> little habit in their support group comp.lang.scheme.
But what happens when mis-information is posted in com.lang.lisp? Should it just be left alone? I agree that we can do without these flame wars, but you certainly don't want to spread lies. Right? What do you think is the appropriate way to handle a situation like this?
NG> But unfortunately, some of them feel the perverted, exhibitionist NG> urge to constantly demonstrate their impediment to the rest of the NG> world, like ``See? I really believe that. Please tell me how sick NG> and filthy I am!'' The same goes for Dylan.
Keep in mind that the "ludicrous" quote above came from a flame war started by a CL'er. He started off by providing some mis-information about Scheme, and when I attempted to clear up the point got dragged into an all out flame war. Of course it is my fault -- I should have not taken the bait. Or, should have tried to correct the information and not responded after that. But I fell for it. Still, it was spawned by a CL'er, not a Schemer.
I'm not trying to place blame on anyone here. I just agree with you trying to determine which is a better language (CL or Scheme) is silly and is just going to get you into a flame fest.
(Now, I can't wait to see what this post spawns...)
(1) Who wants clear air? (Hint - not the participants.)
(2) If you think that technical merit is decisive, you don't understand the question.
(3) The only possible result of a "shootout" is that programmer A should write application B in language C. Since that result is usually available before the shootout....
(4) If you're looking for great insight in program snippets....
(5) Evaluating programming languages by looking at implementations of trivial algorithms/applications is ....
(6) Constraints that eliminate classes of applications that people care is ....
(7) It's been done, many times. If it didn't have the desired result then, why will this time be any different?
-andy
ps - The answer to "Is Computer Science filled with mediocrity?" is "no - it is 90% crap like everything else".
Benjamin Simon <b...@atom.amazingmedia.com> writes:
...
> Keep in mind that the "ludicrous" quote above came from a flame war > started by a CL'er. He started off by providing some mis-information > about Scheme,
I am the CLer and I did not spread misinformation. I may have chosen my words poorly but the semantics is still valid.
Scheme does not have a OO in the standard (meanign something similar to Smalltalk, C++, Java, CLOS, Eiffel, Ada95, Python, etc etc). CL does.
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
> > Is there anything in Scheme that is comparable to the CL loop macro?
> Thankfully no. There is named let, however. ;)
It is just one short macro away :)
> Is there anything in CL that is comparable to call/cc?
No. For most uses of call/cc you have equivalent higher level constructs in CL (think the condition system, aka "exceptions"). Essentially what you lack in CL is the possibility to use continuations to "save the state" and resume computation later in a generalized way. In CL you only have a restricted form with "restarts".
OTHO, call/cc is not all that useful when implementing multidimensional arrays, hash tables, etc etc. :)
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
> Marco Antoniotti wrote: >> (make-array (list 3 3 3) :initial-element 0.0d0 :element-type 'double-float) >> Please include the whole multidimensional array library (or a pointer >> to the full blown implementation) in your Scheme reply :)
> Using Kawa (http://www.gnu.org/software/kawa/), which implements > SRFI 4 (Homogeneous numeric vector datatypes) and SRFI 25 > (Multi-dimensional array primitive). Kawa extends the latter > to allow share-array to be passed arbitrary vectors (including strings).
Ah, but that's not specified by R5RS, so it may be safely ignored as being a non-Scheme figment of the imagination. -- (concatenate 'string "cbbrowne" "@cbbrowne.com") http://www3.sympatico.ca/cbbrowne/sgml.html "Linux is obsolete" -- Andrew Tanenbaum
Christopher Browne <cbbro...@acm.org> writes: > Quoth Per Bothner <p...@bothner.com>: >> Marco Antoniotti wrote: >>> (make-array (list 3 3 3) :initial-element 0.0d0 :element-type 'double-float) >>> Please include the whole multidimensional array library (or a pointer >>> to the full blown implementation) in your Scheme reply :)
>> Using Kawa (http://www.gnu.org/software/kawa/), which implements >> SRFI 4 (Homogeneous numeric vector datatypes) and SRFI 25 >> (Multi-dimensional array primitive). Kawa extends the latter >> to allow share-array to be passed arbitrary vectors (including strings).
> Ah, but that's not specified by R5RS, so it may be safely ignored as > being a non-Scheme figment of the imagination.
That's okay. Since the IEEE Scheme standard expired the language itself is a figment of the imagination. IE, only useful to imaginative users. No good for commercial applications, of course.
Stephen J. Bevan <step...@dino.dnsalias.com> wrote:
>[...] >I agree, but it can be used to implement an event driven system which >is is based around select/poll/queue listening on non-blocking >file-descriptors. Using call/cc is is possible to write much of the >code as if it is executing in separate "threads" as long as you are >careful to implement any I/O calls using non-blocking I/O and call/cc >to hook a continuation into the event distribution mechanism.
That's actually what I intended, too.
>You can of course do this without call/cc but not without writing much >of the application code in a continuation-passing style. I don't mind >that too much myself but it certainly isn't going to win any clarity >contests compared to the direct version (that uses call/cc underneath).
That's what I've done even in C++ many times. Of course, in C++ it's much more icky than it'd be in Lisp or even any modern statically typed functional language, regardless of whether it's Haskell or some ML.
>One thing I've yet to determine is which of the the call/cc or CPS >version actually performs better for various implementations. If it >turns out CPS is significantly better (enough to make up for the code >contortions) then it would put an end to the only practical use I've >ever made of call/cc.
It probably depends on the implementation. If the implementation does full CPS transform, performance will probably be nearly equal between both approaches: call/cc will be comparatively cheap. If there's significant stack copying or so involved for call/cc, your manual CPS transform will turn out better.
Of course, I'd have not too much problem with a de-facto standard for cheap enough concurrency (meaning: no thread preemption required, but threads should cost less than the memory for a separate stack per thread) either. Things like Concurrent Haskell (in GHC's implementation, it costs about 1 to 2 kb of fixed overhead per thread, WITH thread-preemption), Concurrent ML in SML/NJ's implementation (SML/NJ does a full CPS transform, offers a call/cc equivalent but also thread primitives which are implemented by continuation switching plus a preemption mechanism), or Erlang (thread costs significantly below 1 kB of memory) come to mind.
It happened earlier this year I think. Chris Haynes posted to comp.lang.scheme in December of 2001 saying that the IEEE Scheme standard was timing out and that if interested parties felt it was necessary or worthwhile to renew it they should do so soon.
d...@goldshoe.gte.com (Dorai Sitaram) writes: > >| Since the IEEE Scheme standard expired
> > When did this happen and why was it allowed to?
> It happened earlier this year I think. Chris Haynes > posted to comp.lang.scheme in December of 2001 saying > that the IEEE Scheme standard was timing out and that > if interested parties felt it was necessary or > worthwhile to renew it they should do so soon.
This is an issue I've thought a great deal about.
Other than churning more fees from the community and making people spend a lot of money on process that is better spent on product, can anyone cite a material difference it makes whether there is a present or past standard? I'd be curious to know an actual documented case where it turns out to matter.
* Kent M Pitman | Other than churning more fees from the community and making people spend a | lot of money on process that is better spent on product, can anyone cite a | material difference it makes whether there is a present or past standard? | I'd be curious to know an actual documented case where it turns out to | matter.
It matters when you have a legal dispute over a bug in an implementation that causes significant problems that somebody has to pay for. This does not happen in a language that is only used for toy purposes and nobody cares much about the standard, since everybody program to an implementation, anyway.
-- 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.
Erik Naggum <e...@naggum.no> writes: > * Kent M Pitman > | Other than churning more fees from the community and making people > | spend a lot of money on process that is better spent on product, > | can anyone cite a material difference it makes whether there is a > | present or past standard? I'd be curious to know an actual > | documented case where it turns out to matter.
> It matters when you have a legal dispute over a bug in an > implementation that causes significant problems that somebody has > to pay for. This does not happen in a language that is only used > for toy purposes and nobody cares much about the standard, since > everybody program to an implementation, anyway.
Maybe you're intending to answer for this case, but I didn't ask as specifically as I should have. Let me restate and elaborate my question/comment and see if it changes your answer.
I really meant the case of an expired standard. Is there substantial evidence to believe that people regard "expired standards" at the same level as "toy". Or do they secretly understand that an expired standard can still be a real standard and that it's just a hassle to renew.
For example, their been suits made (or suits known to have been declined to be made) based on the expiredness of some language standard.
You see, personally, I think it's nuts to say a standard expires. I think it's like asking someone if he wants to renew his nobel prize or asking an author if they want renew not their copyright but their authorship.
Sure, the standards organization can claim that by not renewing it has lost credibility, but I find that a foolish default. I'd rather say that to lose credibility, you have to take specific community action and that otherwise a standard merely continues to stand.
I know the standards bodies make the claim that without periodic review you cannot know this, but I think that's not really true. While consensus about MEANING of a standard is important, I don't think consensus about "still usefulness" of a standard is important. If there is even one user of a past standard, then I think that standard retains its significance to that user and for others to vote them out is nutty.
I think this is just a revenue churning game by standards organizations, and I resent it.
There is something weirdly 1984-ish about calling up IEEE and having them say "Scheme standard? What Scheme standard? We never heard of a Scheme standard." (OK, the conversation wouldn't probably go just like that, but perhaps you get my point...)
This is all just my private opinion and is not, for example, the official policy of any standards organization I might have previously represented (heh), nor is it the opinion of any company I now or have previously represented.
In the last exciting episode, Erik Naggum <e...@naggum.no> wrote::
> * Kent M Pitman > | Other than churning more fees from the community and making people > | spend a lot of money on process that is better spent on product, > | can anyone cite a material difference it makes whether there is a > | present or past standard? I'd be curious to know an actual > | documented case where it turns out to matter.
> It matters when you have a legal dispute over a bug in an > implementation that causes significant problems that somebody has > to pay for. This does not happen in a language that is only used > for toy purposes and nobody cares much about the standard, since > everybody program to an implementation, anyway.
I would think lawsuit thing would be much more likely to happen with regard to the conformance of Ada implementations with their relevant standards.
After all, they do use Ada to do things like controlling guided missiles and nuclear weapons, and, well, people that are in the market for nuclear weapons _are_ likely to be more than a little anal-retentive about such details... -- (concatenate 'string "chris" "@cbbrowne.com") http://cbbrowne.com/info/nonrdbms.html Rules of the Evil Overlord #157. "Whenever plans are drawn up that include a time-table, I'll post-date the completion 3 days after it's actually scheduled to occur and not worry too much if they get stolen." <http://www.eviloverlord.com/>
* Kent M Pitman | Maybe you're intending to answer for this case, but I didn't ask as | specifically as I should have. Let me restate and elaborate my | question/comment and see if it changes your answer.
I understood your quesetion the way you intended. I think an expired standard is harder to use as a legal reference than a "live" standard, but if you cannot actually get a vendor to state their conformance in writing, it is a moot question, anyway. I think conformance clauses that require only products that purports to conform to the standard be called by the name of the standard would be more useful than non-expiring standards. Then it would say in the product documentation or even its splash/banner that it is a Common Lisp, say, because it purports to conform to the standard and that it would be a serious infringement (of some kind) to call something a Common Lisp if it did not so state.
| Or do they secretly understand that an expired standard can still be a real | standard and that it's just a hassle to renew.
I think people regard an expired standard as expired for a reason. A renewal is a good signal from the community that it cares enough about the standard to maintain it. Failure to send that signal could be interpreted as meaning that anything goes and that the community no longer cares about conformance to this standard. At the very least, those who depend on it should scrounge up the monies to renew it if that is what is required.
| You see, personally, I think it's nuts to say a standard expires. I think | it's like asking someone if he wants to renew his nobel prize or asking an | author if they want renew not their copyright but their authorship.
Well, I agree that it is nuts that it expires -- there should instead be a move to obsolete a standard -- but when the standards bodies require it, you either play their game or you lose by default. If you want to move that a particular standard should not expire despite the rules that are intended to expire defaultly obsoleted standards. there are rules to that effect, too, if you want to get ineto the politics of IEEE standardization.
Not that I think this matters for Common Lisp concerns. I would find a way to get the money to pay ANSI to keep ANSI X3.224 alive for however long it requires. (I even toyed with the idea of having one of the Bible printers produce a gilded, leather bound version of the standard on their fine India paper. When they can do that with dictionaries, they can do it with real reference works.)
-- 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.
