Dear Lispniks,
under the impression of this thread and the
vivacious response of this post, I've started
to tinker with a "Readers Digest of arguing over
non-technical Lisp-issues". This document is
supposed to save bandwidth, calories and nerves
in the future. Imagine aksing the next "troll"
not to go and boil his head, but to point him
to the "Readers Digest", tell him to read a certain
section and come back if he feels that his
question or statement is not covered comprehensively
in the document. The document is not FAQ because
it does not give a definite answer but explains
points and counterpoints. Thus it is more like
a wikipedia-entry on controversial issues like
"intelligent design". I will try to make the
rendering of explanations as unbiased as possible.
Ideas and suggestions are always welcome, my
email address is ···········@gmail.com.
Although I've checked the web for a "Trolling
Guide to c.l.l." I've not found any, and several
people in this thread have expressed their
frustration over lack of such a document.
The document might also contain a brief guide to
civilized arguing for c.l.l.-participants. I think
becoming worked up over statements like "Lisp
sucks dead maggots thru a straw" is understandable,
but the heat over observations like "perl has
a single, canonical implementation, so I dare
speculate that..." is not. The fact that Peter Seibel's
Gardeners project exists is an indication that
not everybody is a happy camper, and rightly so.
Even newbies and outsiders should be free to
be interested in "issues". Treating these
"issues" like the old, demented grandma in the
basement does not help anybody. However, rejoice!
With a comprehensive digest of disputable issues
your life on c.l.l. and dealing with newbie
posts will become much easier!
One problem I see here is feedback. As the past
has shown, putting a document somewhere on
the web and pointing there from a c.l.l.-post
is not effective because virtually nobody was
interested in following the link. Was it
because a page on angelfire is considered
totally low-class and a reason for distrust,
perhaps? Feedback is important, but how can
I get any?
There are a lot of dangling interesting subthreads
from many appearantly well-informed and bright people
here, but I won't have much time to follow up to
many of those in the next days, and apologize for
this. I will try to work thru the backlogs
beginning next week, so please be patient.
Anyways, here is a brief /introduction/ to the
Troll-Reader's-Digest:
Introduction
Lisp is an interesting language with a long tradition and a devoted
user-base. If you are new to comp.lang.lisp you might not only
have purely technical questions, but also questions like:
* Why doesn't Lisp have wide industry acceptance, despite its utter
coolness?
* Why is it more difficult to use socket-, threading- or
webframeworks in Lisp than in perl, python or PHP?
* Wouldn't it be better for Common Lisp to have a benevolent
dictator like python instead of a standard and several implementations?
Be aware that such questions might look innocent and benign to you, but
there are many such questions that can enrage participants on
comp.lang.lisp and are thus guaranteed to instigate a flamewar, with the
result that you might be tainted as a troll. Be also aware that in some
cases even the vindicability of statements like "Lisp's fragmentation is
a problem because..." is up to dispute and might put you into the middle
of a flamewar. In other words, even the legitimacy of such questions is
discussed frequently on c.l.l. If you feel tempted to share your musings
on the nature of Lisp or what you think are its handicaps in some way or
other on c.l.l., please read on. This document is a sort of Reader's
Digest to flamewars on non-technical topics from arguments on c.l.l. in
the past. If you plan to ask non-technical questions on c.l.l. you
should make sure that your question, point of view or observation is new
and original, or, at least not covered in this document.
This document is *not* a FAQ in the conventional sense of the term. It
does not answer questions in a definite way. It is more of a guide to
prominent disputes, some of them have been with Lisp for a very long
time. Various points and counterpoints have made it into Lisp's
folklore, thus bringing up the same issues over and over again on c.l.l.
is frustrating for veteran lispniks, even if you trigger an avalanche of
flames in good faith. You can consider knowing this folklore of arguing
as an important part of being a real lispnik.
Interesting idea, I like it. I'm sure that there are folks over at
CL-Gardiners that would enjoy contributing to this :)
http://www.lispniks.com/cl-gardeners/
Brad
Actually, I really ment "amusing idea". I'm sure that some people
won't find it so amusing though :)
And, you should probably mention that any flamewar can be averted by
saying "I have fixed <flame war inducing subject>"
For example - "I have fixed Lisp's problems with sockets by writing a
socket layer that works on all known Lisps and platforms"
Brad
Joe Marshall wrote:
> > Although I've checked the web for a "Trolling
> > Guide to c.l.l." I've not found any...
>
> The trolls don't seem to need instruction.
How do you know? Perhaps with a good Trolling Guide to CLL, there would
be more quality trolls?
I haven't much time, but here are the basics:
Question Common Lisp's being a compiler
Complain about #'
Complain about parentheses.
Post speed comparisons to for(;;) loops in C
Remind the readers that macros are evil - that's why C++ has templates
Ask how to make an *.exe file
Write a readtable that makes Lisp look like Java
Create a fake livejournal blog where a hot CS co-ed talks about how
happy she is that she doesn't have to use Lisp anymore :-)
Happy Trolling!
·········@gmail.com writes:
> Joe Marshall wrote:
> > > Although I've checked the web for a "Trolling
> > > Guide to c.l.l." I've not found any...
> >
> > The trolls don't seem to need instruction.
>
> How do you know? Perhaps with a good Trolling Guide to CLL, there would
> be more quality trolls?
>
> I haven't much time, but here are the basics:
Right. And to yank your chain - Stepenov didn't have a clue of what
he was arguing about. Nada.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
·········@gmail.com wrote:
> Joe Marshall wrote:
>
>>>Although I've checked the web for a "Trolling
>>>Guide to c.l.l." I've not found any...
>>
>>The trolls don't seem to need instruction.
>
>
> How do you know? Perhaps with a good Trolling Guide to CLL, there would
> be more quality trolls?
This is really witty. I think the Trollomatic
will be named "The Compleat Guide to Quality Trolling on C.L.L."
Along the lines of "Throwing any of the following
topics into c.l.l. is considered bad taste by many
participants and perceived as poor trolling.
It is thus strongly discouraged. This document
is intended to improve trolling quality on
c.l.l. and should be read by anyone interested in
non-technical matters in Lisp, namely things like..."
>
> I haven't much time, but here are the basics:
>
> Question Common Lisp's being a compiler
This is covered in the FAQ.
> Complain about #'
> Complain about parentheses.
> Post speed comparisons to for(;;) loops in C
> Remind the readers that macros are evil - that's why C++ has templates
> Ask how to make an *.exe file
This is a technical question.
> Write a readtable that makes Lisp look like Java
> Create a fake livejournal blog where a hot CS co-ed talks about how
> happy she is that she doesn't have to use Lisp anymore :-)
Uhm, I'm verry gullible... this one you've made up, didn't you?
However, it sounds like quality trolling to me.
>
> Happy Trolling!
>
Thanks.
Tin Gherdanarra wrote:
> >
> > Happy Trolling!
> >
> Thanks.
You are welcome.
BTW, I got more:
"But Erik Naggum said Java is good" ( *That* is quality trolling. It's
the nuclear bomb of trolls. Luckily, no one has used it in anger)
"Digg beat Reddit. Reddit's realization that Lisp sucks came too little
too late"
"Millions of programmers can't be wrong" (cite some "wisdom of masses"
study)
"Professor Felleisen said every Lisper he knows complains about Common
Lisp macros" (He did on some mailing list. Ask Pascal for a link)
On 2006-02-03 14:54:11 -0500, ·········@gmail.com said:
> You are welcome.
>
> BTW, I got more:
Oh I think you should stick to what comes naturally and continue to
praise the brilliance of Stepanov and the STL on comp.lang.functional.
Raffael Cavallaro wrote:
> On 2006-02-03 14:54:11 -0500, ·········@gmail.com said:
>
>> You are welcome.
>>
>> BTW, I got more:
>
>
> Oh I think you should stick to what comes naturally and continue to
> praise the brilliance of Stepanov and the STL on comp.lang.functional.
>
Yep. That and continue to nonrespond to every criticism of his ideas by
bleating about how every one is ganging up on him. Or maybe just
continue to whine "sockpuppet" because he never learned about addresses
in headers.
Brilliant. Yeah, you sure got "more".
>> Question Common Lisp's being a compiler
> This is covered in the FAQ.
But it has to be in the Reader's Digest, too, since many trolls will go
there first.
·········@gmail.com wrote:
> Joe Marshall wrote:
>
>>>Although I've checked the web for a "Trolling
>>>Guide to c.l.l." I've not found any...
>>
>>The trolls don't seem to need instruction.
>
>
> How do you know? Perhaps with a good Trolling Guide to CLL, there would
> be more quality trolls?
>
> I haven't much time, but here are the basics:
>
> Question Common Lisp's being a compiler
> Complain about #'
> Complain about parentheses.
> Post speed comparisons to for(;;) loops in C
> Remind the readers that macros are evil - that's why C++ has templates
> Ask how to make an *.exe file
> Write a readtable that makes Lisp look like Java
> Create a fake livejournal blog where a hot CS co-ed talks about how
> happy she is that she doesn't have to use Lisp anymore :-)
>
> Happy Trolling!
>
Wetback Wavy wrote:
You guys don't know shit about trolling! Follow my Mexican ass if you
want to learn.
Love,
Wavy G
Wavy G wrote:
>
> Wetback Wavy wrote:
>
> You guys don't know shit about trolling! Follow my Mexican ass if you
> want to learn.
> Love,
> Wavy G
See how it says "Wavy G wrote:" right at the top? See how above the
words I'm typing right now it doesn't say "Do Not Mind Me wrote:"
Are you a fucking idiot Flipper Mike?
If not why do you still not know how to do this? Is it so hard to look
at something and copy it exactly how it is? It's only words you are
copying, boy oh boy are you dumb.
The results are in...Do Not Mind Me, you are NOT the father!
>
>Wavy G wrote:
>
>>
>> Wetback Wavy wrote:
>>
>> You guys don't know shit about trolling! Follow my Mexican ass if you
>> want to learn.
>> Love,
>> Wavy G
>
>
>See how it says "Wavy G wrote:" right at the top? See how above the
>words I'm typing right now it doesn't say "Do Not Mind Me wrote:"
>
>Are you a fucking idiot Flipper Mike?
Oh, it's Flipper Mike? Well, that explains it.
Tell me, Internet, is there any way to "plonk" somewon with the name
"Wavy G" without actually plonking myself?
>If not why do you still not know how to do this? Is it so hard to look
>at something and copy it exactly how it is? It's only words you are
>copying, boy oh boy are you dumb.
Do Not Mind Me wrote:
> Wavy G wrote:
>
>
>>Wetback Wavy wrote:
>>
>>You guys don't know shit about trolling! Follow my Mexican ass if you
>>want to learn.
>>Love,
>>Wavy G
>
>
>
> See how it says "Wavy G wrote:" right at the top? See how above the
> words I'm typing right now it doesn't say "Do Not Mind Me wrote:"
>
> Are you a fucking idiot Flipper Mike?
>
> If not why do you still not know how to do this? Is it so hard to look
> at something and copy it exactly how it is? It's only words you are
> copying, boy oh boy are you dumb.
>
Lol Dance, dance and more dancing for me! You lose yet again! FM...
In article <························@z14g2000cwz.googlegroups.com>,
·········@gmail.com says...
> Joe Marshall wrote:
> > > Although I've checked the web for a "Trolling
> > > Guide to c.l.l." I've not found any...
> >
> > The trolls don't seem to need instruction.
>
> How do you know? Perhaps with a good Trolling Guide to CLL, there would
> be more quality trolls?
>
> I haven't much time, but here are the basics:
>
> Question Common Lisp's being a compiler
> Complain about #'
> Complain about parentheses.
> Post speed comparisons to for(;;) loops in C
> Remind the readers that macros are evil - that's why C++ has templates
> Ask how to make an *.exe file
> Write a readtable that makes Lisp look like Java
> Create a fake livejournal blog where a hot CS co-ed talks about how
> happy she is that she doesn't have to use Lisp anymore :-)
Well, some people think my assertion that it encourages the writing of
self-modifying code is a troll...
- Gerry Quinn
Tin Gherdanarra wrote:
> becoming worked up over statements like "Lisp
> sucks dead maggots thru a straw" is understandable,
I'm sure Lisp *can*, if you want it to ;)
> Anyways, here is a brief /introduction/ to the
> Troll-Reader's-Digest:
[...]
Sounds good.
--
Suffering from Gates-induced brain leakage...
Dear c.l.l.,
here is a brief first installment of the proposed Troll-o-Matic.
It deals with non-technical questions, I will look at the stuff
suggested by other participants next. Feel free to mail or post
comments. Regards Tin
----8<----- CUT HERE ----------------------------------->8------
The Compleat Troller's Guide To C.L.L.
This document is intended for people interested in potentially
controversial questions regarding the Lisp programming language. Since
these questions are sure-fire hits for stirring up a commotion on
comp.lang.lisp, using such cheap gimmicks to make participants on
c.l.l. angry is considered bad taste, unsportsy and poor trolling.
This document is written in the hope that it will improve trolling
quality on c.l.l. If you plan to troll on c.l.l. in interesting and
achieved ways, this document is for you. It is not a HOW-TO, though,
it is a HOW-NOT-TO. BE CREATIVE, BE INNOVATIVE.
=== A note to the c.l.l. regulars
Although the following suggestions apply to all newsgroups
universally, comp.lang.lispniks in particular are asked to be tolerant
towards newbies and idiots whenever possible. Lazyness, impatience and
lack of mental capabilities are part of the human condition, but so is
delight in sharing and teaching. Getting worked up over waste of
bandwidth in a newsgroup creates more waste of bandwidth. A stupid
rookie question might be answered by a slightly less stupid rookie who
is glad to help out. The idiot who is unable to use google might be
well served by another participant who *can* use google and is still
enthusiastic enough to help out. If you see a trivial technical
question, try to ignore it. It takes two to fan poor trolling and you
probably DO NOT WANT TO PARTICIPATE IN SUCH NONSENSE.
=== "Lisp sucks"
Saying that X sucks on a newsgroup named comp.lang.X is the safest,
and thus cheapest way of starting a flamewar. It goes without saying
that "Lisp sucks" is very poor trolling. Not even refininig your
thesis to "Lisp sucks because..." makes it any better. Your
observation that is the cause for your conclusion that Lisp sucks
might be correct, but it does not mean that Lisp in general sucks. For
example, you might be correct in noticing that Lisp uses more "(" and
")" parantheses than other programming languages, and it might also be
correct that it drives YOU crazy. Inferring from this that Lisp sucks
is NOT necessarily a universal concept. Whether a particular feature
or lack thereof really contributes to Lisp's perceived suckage might
be a matter of interpretation or preferences. Some participants might
consider the feature or lack thereof a /good thing/. Personal
experiences and technical sophistication vary, so there is not always
a last word on how or if things could be improved. Moreover, Lisp has
the undeserved reputation of lacking some features when in fact it
does not. Classic examples are "lack of compound data types other than
lists: arrays, structures, etc." Many such allegations are urban
myths, so you should make sure that Lisp really lacks the feature you
miss. A significant part of the "Lisp FAQ" is dedicated to those urban
myths, so you should read it before trolling on c.l.l. Otherwise you
are in danger of getting the deserved reputation of being a cheap
troll. Some c.l.lispniks might reprieve you to "idiot", but you might
not consider this an improvement. People acting in good faith because
they are unaware of the explosive trolling power of some Lisp issues
are usually not exempt. READ THE FAQ.
=== "Lisp gives you a hard time"
More often than not, this observation relates to a specific Common
Lisp package, not Lisp's syntactical peculiarities. As pointed out by
many seminal documents, it's the syntactical peculiarities that give
Lisp its power. This fact is well understood by most people interested
in Lisp and not further discussed here. However, many a newbie's
enthusiasm evaporates when they find out that they can't make their
desired open source package work for their preferred Common Lisp
implementation. Venting frustration over usability issues or
documentation gaps is a fool-proof route to interrupting civilized
conversation and infuriate the audience, so it is strongly
discouraged. If you have problems with a certain open-source Lisp
package you should make sure you that google or the package's mailing
list can't answer your question. If it is difficult to find the
information you need or you have to fix something, but you do find or
fix it, comtemplate documenting the process somewhere to make Lisp
easier to use for other people. Lisp newbies who have experience with
other open source programming languages will probably find that using
packages for things like the web, threads, regular expressions or OS
interfacing are harder to use than their corresponding modules for
java, perl, python or PHP, for example. Although such an observiation
might be correct in your particular case, it is not necessarily true
for all Lisp implementations or equivalent open-source packages in
general. Moreover, commercial Lisp implementors put considerable
effort into their packages for the web, threads, OS interfacing and
the like. Even if you are not complaining about your bad experience,
merely pointing out that it's all much easier in perl or python or
java you will be perceived as
* stating the obvious.
* whiny.
* wrong because it's all a no-brainer in Allegro Common Lisp
* a troll.
* all of the above.
With ridiculously little effort, the debate over "hard to use" topics
can be escalated to all sorts of stereotypical flamewars fanning out
into various subthreads concerning the legitimacy of lazyness,
whinyness, elitism or idiocy. Usually these threads are not an
interesting read for regular c.l.lispniks because the points and
counterpoints have been repeated so often. Sometimes a regular
participant jumps into such a discussion out of sheer boredom and
rants in frustration with poor trolling and wants his bandwidth back.
Don't let that happen. Before bringing up a "hard to use" issue you
should read the following sections to make sure that it has not been
comprehensively covered by previous debates and is thus part of this
document. USE GOOGLE, BE POLITE.
=== "Lisp is hard to use because it is
=== less popular than more popular programming languages"
Again, you might make this statement in good faith, expressing concern
over Lisp's obscurity and the benefits to usability, documenation and
"infrastructure" that come with wide adoption of a programming
language, especially in the world of open source software. You might
feel that, if Lisp had as many users as python, it's packages might be
as easy to use as perl's. You might wax philosophically on how neat
that would be. Your good-natured motives have no influence on the
effects of your post, however, because they disappoint the audience
just as much. Obscurity and misunderstandings have been with Lisp
since its inception in 1959 and have been talked about, whished about,
punned about and ranted about exhaustively, not only on c.l.l. The
statement that many hands make light work, that a larger user-base is
better for everyone in that user-base, that a larger mindshare means
more jobs -- all these and similiar statements are platitudes even
pointy-haired bosses have learned in the meantime. Re-iterating
PHB-wisdom on c.l.l. does not make you appear wit or original, and
other participants will take the liberty to remind you to this clear
fact. This means that defending your motive in the midst of a flamewar
with "but all I wanted to say is that, if only..." is highly
uneffective because it gets you more flak and lowers trolling qualitiy
to zero asymptotically. A typical continuation to this defense is an
argument over perceived, or real elitism in lispnik circles. DO NOT
PLAY THE "LISP IS HARD TO USE"-card. Elitism gets us to the next
section. "Lisp is hard to use and arrogant elitists who consider this
a good thing are arrogant elitists" Sometimes the arguing over your
difficulties with one or more packages or Lisp in general brings out
the worst in seasoned experts: In a desperate attempt to get at least
some modest entertainment out of a stale thread, they might troll back
on you by posting that you are the problem, not Lisp, and that Lisp
simply is not a programming language for idiots like you. If you see
this thesis in your trolling operation you should not try to debunk it
by pointing out that that's "an elitist point of view and thus
condemnable". Appealing to the poster's egalitarian conscience in
order to explode his point is not as effective on c.l.l. as it is on
alt.politics.correct. The simple reason is that the poster might not
have an egalitarian conscience to begin with. He might feel very good
as black-belt Lisp hacker hovering above the unwashed masses of
wannabes and tell you so, making the thread even more uninteresting
and predictable in the process. Teasing black-belt Lisp hackers by
implying that their sophistication is a disadvantage for less
sophisticated users is a slam-dunk to getting everybody worked up on
the sheer idiocy of this rhetorical manoevre, thus it is considered
very amateurish trolling. DO NOT TALK ABOUT ELITISM.
On 2006-02-15, Tin Gherdanarra <···········@gmail.com> wrote:
> Dear c.l.l.,
>
> here is a brief first installment of the proposed Troll-o-Matic. It
> deals with non-technical questions, I will look at the stuff
> suggested by other participants next. Feel free to mail or post
> comments. Regards Tin
I, for one, enjoyed reading your guide. To me, it contains an
interesting (even humorous) mix of good advice to c.l.l. newbies, and
deadpan irony.
I think you should point out to your reader that, if they bitch about
"such-and-such package sucks/has bad documentation/etc", and that
package is open-source, they will be invited to fix it, bitch about it
on the package's mailing list, or shut up. If it's not open source,
they will be invited to complain to their vendor. On the other hand,
if they *ask for help* with such-and-such package, they may actually
receive it, or they may still be invited to ask on the package's
mailing list.
-- Larry
> using such cheap gimmicks to make participants on
> c.l.l. angry is considered bad taste, unsportsy and poor trolling.
> This document is written in the hope that it will improve trolling
> quality on c.l.l. If you plan to troll on c.l.l. in interesting and
> achieved ways, this document is for you. It is not a HOW-TO, though,
> it is a HOW-NOT-TO. BE CREATIVE, BE INNOVATIVE.
Overall, the essay is rather discouraging, particularly for one who is
new to trolling. If all the easiest forms of trolling are off limits,
then how is a new troll to get started in life? And for those who have
been practicing for some time, what alternative practices might lead to
progress in their trolling careers. Consider a layout similar to the
following. Simple and effective trolling practices, such as asking
about the relative merits of Common Lisp vs {Scheme, Perl, Fortran}
should be recommended only for newbies as they get their feet wet.
Also, consider making some of your assumptions about quality trolling
more explicite. What is quality trolling? What are the marks of a
quality troll? Do you have any examples of quality trolling or
discussion of trolling motivation?
Consider this layout, which troll rookies might find more inviting, and
which allow more advanced trolls to skip the parts they don't need.
1) What is trolling? Why should I consider becoming a troll?
2) First steps. I want to become a troll. How should I start?
3) Common newbie mistakes, and how not to get plonked on your first
round of trolling.
4) Trolling tradition in c.l.l. Special considerations for trolling
among the Lispniks.
5) The rise to mastery. Advanced trolling techniques.
6) Case studies. Legends of c.l.l trolling.
7) Inspirational sendoff. Be innovative. Immitating the masters isn't
enough. Learn from them, but develop your own personal trolling style.
Start your own trolling legend.
Eric Lavigne wrote:
>
> Overall, the essay is rather discouraging, particularly for one who is
> new to trolling. If all the easiest forms of trolling are off limits,
> then how is a new troll to get started in life? And for those who have
I don't think it is that discouraging - just that CLL is not the place
for a n00b troll. They should cut their teeth on easier to troll news
groups :)
> been practicing for some time, what alternative practices might lead to
> progress in their trolling careers. Consider a layout similar to the
> following. Simple and effective trolling practices, such as asking
> about the relative merits of Common Lisp vs {Scheme, Perl, Fortran}
> should be recommended only for newbies as they get their feet wet.
> Also, consider making some of your assumptions about quality trolling
> more explicite. What is quality trolling? What are the marks of a
> quality troll? Do you have any examples of quality trolling or
> discussion of trolling motivation?
I think that Xah Lee should be looked at as a perfect example of
quality trolling - right now there is an active thread of his with 91
posts, only 11 are from Xah - an astounding troll:reply ratio if you
ask me. Infact, he is so good that the mere mention of his name will
be seen by some as a troll - I expect my mentioning him will draw
someone out in this thread!
I like your 7 step program to trolling!
Brad
PS, I find this thread really good, and really funny.
Tin Gherdanarra wrote:
> The Compleat Troller's Guide To C.L.L.
Excellent post Tin!
[...]
> === A note to the c.l.l. regulars
>
> The idiot who is unable to use google might be
> well served by another participant who *can* use google and is still
> enthusiastic enough to help out. If you see a trivial technical
> question, try to ignore it. It takes two to fan poor trolling and you
> probably DO NOT WANT TO PARTICIPATE IN SUCH NONSENSE.
Hear hear! I'm an example of the idiot who can not use google (see
"macros and lisp-2" posting of mine a few weeks back), Pascal is an
example of a very knowledgeable lispnik who *can* use google and is
tolerant of idiots and Kaz is the curmudgeon with a short fuse who,
underneath it all, has a heart of gold even if he does not suffer fools
willingly.
I must compliment c.l.l on the fairly low ratio of flames to serious
answers I got to my stupid question. Heck, even the spanking Kaz gave
me was useful.
====
Going a little off topic (or perhaps going more on topic) ...
http://www.ffconsultancy.com/free/ray_tracer/languages.html
I recently read about the benchmark above and boy did ocaml (and
stalin) kick Lisp's ass 3 ways to sunday.
You'd think Lisp could at least be competitive with Java on the
verbosity front if not beat it on performance. Is ocaml really that
much better than lisp? What major language features, if any are
present in CL and ocaml and not in the other (e.g. macros)?
Also, what is the secret of Stalin's success? Perhaps SBCL can be
converted to despotism and reap similar rewards.
(for all you other noobs who are even more clueless than I, that was an
example of "D-" trolling. I obviously have much to learn before I can
troll with the big boys)
--jfc
funkyj wrote:
<snip>
> ====
>
> Going a little off topic (or perhaps going more on topic) ...
>
> http://www.ffconsultancy.com/free/ray_tracer/languages.html
>
> I recently read about the benchmark above and boy did ocaml (and
> stalin) kick Lisp's ass 3 ways to sunday.
>
> You'd think Lisp could at least be competitive with Java on the
> verbosity front if not beat it on performance. Is ocaml really that
> much better than lisp? What major language features, if any are
> present in CL and ocaml and not in the other (e.g. macros)?
>
> Also, what is the secret of Stalin's success? Perhaps SBCL can be
> converted to despotism and reap similar rewards.
I suspect that Lisp's runtime type system is the problem here. ocaml,
Java and C++ are (as far as I am aware) largely statically typed
systems. ocaml doesn't often require type declarations as it infers
them where possible. In this extremely math heavy example, static
typing is a big win. Stalin is an agressive Scheme compiler that does
whole program analysis (that is presumably why it takes so long for
even a trivial example), so I suspect that Stalin is removing all
runtime type checking because that is possible in this example.
I suspect the Lisp speed could be further increased at the cost of
verbosity.
Also, you should be aware that the author of the study shows a bias
toward statically typed languages - I don't know if that will skew
results.
But yes, in this floating point intensive example, Lisp (at least SBCL)
gets beaten like a red-headed stepchild.
Cheers
Brad
bradb <··············@gmail.com> wrote:
> But yes, in this floating point intensive example, Lisp (at least SBCL)
> gets beaten like a red-headed stepchild.
It's not a fp intensive test, but more of a garbage collection
benchmark. It would be significantly faster in newer SBCL versions. It
would be significantly faster if the damage that Dr. Harrop has
inflicted on the Lisp code were undone. Or it could be made faster
still with a bit of simple macrology, which Dr. Harrop is unable to
replicate in other languages, and is apparently therefore an unfair
optimization.
--
Juho Snellman
Juho Snellman wrote:
> bradb <··············@gmail.com> wrote:
> > But yes, in this floating point intensive example, Lisp (at least SBCL)
> > gets beaten like a red-headed stepchild.
>
> It's not a fp intensive test, but more of a garbage collection
> benchmark. It would be significantly faster in newer SBCL versions. It
> would be significantly faster if the damage that Dr. Harrop has
> inflicted on the Lisp code were undone. Or it could be made faster
> still with a bit of simple macrology, which Dr. Harrop is unable to
> replicate in other languages, and is apparently therefore an unfair
> optimization.
Out of curiosity, was the SBCL garbage collector in older SBCL's poor
in comparison to the other languages? I am guessing that ocaml is
collected. And I agree that macros could help the code. To be honest,
I'd really like to see what good lisp code for this benchmark looks
like - to a neophite like me it doesn't look _that_ bad, but I wouldn't
know until it was profiled.
And (like you it seems) I don't buy the "I won't use it because other
languages don't have it" argument - isn't that precisely the point of
choosing one language over another?!
Oh well, I don't think we would convince Dr Harrop to change the study
so that Lisp is in a favourable light - at least not until Lisp is
statically typed :)
Brad
LOL - I just looked at all the code samples. He's counting Lines of
code, right? Scheme and Lisp are the only code samples that have
newlines between blocks of code, all the others are jammed together!
Brad
Yes, it is quite laughable. Here is his example of how much more
verbose Lisp is than OCaml:
> Stalin:
>
> (define (dot a b)
> (+ (* (point-x a) (point-x b))
> (* (point-y a) (point-y b))
> (* (point-z a) (point-z b))))
>
> OCaml:
>
> let dot a b = a.x *. b.x +. a.y *. b.y +. a.z *. b.z
While many folks consider it good style to use verbose names and
multiple lines like the Stalin code above, One could just as easily
have written
> (defun dot (a b) (+ (* (x a) (x b)) (* (y a) (y b)) (* (z a) (z b))))
As was done in the SBCL code and which, like the corresponding OCaml
code, is a single line.
"funkyj" <······@gmail.com> writes:
> Yes, it is quite laughable. Here is his example of how much more
> verbose Lisp is than OCaml:
>
> > Stalin:
> >
> > (define (dot a b)
> > (+ (* (point-x a) (point-x b))
> > (* (point-y a) (point-y b))
> > (* (point-z a) (point-z b))))
> >
> > OCaml:
> >
> > let dot a b = a.x *. b.x +. a.y *. b.y +. a.z *. b.z
>
> While many folks consider it good style to use verbose names and
> multiple lines like the Stalin code above, One could just as easily
> have written
>
> > (defun dot (a b) (+ (* (x a) (x b)) (* (y a) (y b)) (* (z a) (z b))))
>
> As was done in the SBCL code and which, like the corresponding OCaml
> code, is a single line.
Nonsense. No sane person would define a global function x in scheme so (x a)
in scheme is certainly *not* analogous to (x a) in CL or a.x in ocaml.
In this limited context, the above comparison is accurate and fair.
'as
bradb wrote:
> LOL - I just looked at all the code samples. He's counting Lines of
> code, right? Scheme and Lisp are the only code samples that have
> newlines between blocks of code, all the others are jammed together!
The update includes an equivalent graph showing byte counts. The results are
not changed. However, I think the Lisp code contains only spaces whereas
the OCaml code contains tabs, which is unfair. So I'll try non-whitespace
characters next...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
bradb <··············@gmail.com> wrote:
> Out of curiosity, was the SBCL garbage collector in older SBCL's poor
> in comparison to the other languages?
It had some notable weaknesses, especially on modern hardware (many of
these issues are discussed in blog posts at <http://jsnell.iki.fi/blog/>).
I don't know how it stacks up against other GC implementations.
--
Juho Snellman
My 2 cents about good trolling in c.l.l. would be about
"making games with Lisp" question usually raised by trolls and "
wanna -be-game-developing-lispers-but -i-don't-want-to-code" that
enrages real lispers that are not interested in making games but don't
agree that lisp can't be used in this area.
Abuse this while you can because very soon lispers will have one game
engine
to start working with .
bobi
>"making games with Lisp"
> ...
> very soon lispers will have one game
>engine to start working with .
Perhaps more. Looking at how many game-oriented programmers are working
on the Application Builder project, I wouldn't be surprised if it
turned into a game engine.
http://www.lispbuilder.org/
* Frank Buss
Windows programming, testing for LispWorks
on Windows, Mac and Linux
* Artur Maciag
interested in 2D and 3D gaming, wxCL, MySQL
and Postgres connection, wants to help with CFFI
* Justin Heyes-Jones
CFFI wrappers for SDL, game programming, AI
Then there's the commercial engine that you're working on porting to
Lisp. I haven't been following the newsgroup very closely, so I
probably missed one or two. It's an exciting time to be a Lispnik.
bradb wrote:
> Out of curiosity, was the SBCL garbage collector in older SBCL's poor
> in comparison to the other languages? I am guessing that ocaml is
> collected. And I agree that macros could help the code. To be honest,
> I'd really like to see what good lisp code for this benchmark looks
> like - to a neophite like me it doesn't look _that_ bad, but I wouldn't
> know until it was profiled.
I would like to see what a competitively-fast Lisp version looked like.
> And (like you it seems) I don't buy the "I won't use it because other
> languages don't have it" argument - isn't that precisely the point of
> choosing one language over another?!
Indeed, which is why I have allowed this. However, the results are not
affected (the fifth versions are all quicker and longer).
> Oh well, I don't think we would convince Dr Harrop to change the study
> so that Lisp is in a favourable light - at least not until Lisp is
> statically typed :)
I believe that an equivalent benchmark with a task based upon evaluating a
program written in another language (i.e. an interpreter/compiler) would
show Lisp in a much better light.
I have been considering plotting an equivalent graph for Prolog interpreters
written in different languages. However, an interpreter could contain some
clever (and long) optimisations that are not exploited by whatever test I
choose, so this is a little dubious.
Anyway, the ray tracer is only meant to be a little fun.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> writes:
> I believe that an equivalent benchmark with a task based upon evaluating a
> program written in another language (i.e. an interpreter/compiler) would
> show Lisp in a much better light.
Why don't you try implementing something like <http://weitz.de/cl-ppcre/> in
various languages? IIRC Edi Weitz wrote this just to win a bet with a friend
and I'd assume that perl's regexp engine has seen orders of magnitude more man
years of optimization work and AFAIK it's still slower.
So prima facie (haven't much looked into it) this would look to me like a good
example for a simultanous dramatic boost in programmer productivity and
program performance due to lisp technology.
'as
Alexander Schmolck wrote:
> Why don't you try implementing something like <http://weitz.de/cl-ppcre/> in
> various languages? IIRC Edi Weitz wrote this just to win a bet with a friend
> and I'd assume that perl's regexp engine has seen orders of magnitude more man
> years of optimization work and AFAIK it's still slower.
>
> So prima facie (haven't much looked into it) this would look to me like a good
> example for a simultanous dramatic boost in programmer productivity and
> program performance due to lisp technology.
Excellent idea!
I'll look at this in more detail. It certainly sounds easier than
trying to implement interpreters/compilers equivalently in different
languages. ;-)
Cheers,
Jon.
Jon Harrop <······@jdh30.plus.com> writes:
> [...]
>
> Anyway, the ray tracer is only meant to be a little fun.
Is it really? I first came to Lisp last May, and even then you were
filling comp.lang.lisp/comp.lang.scheme with these silly benchmarks
and even then people were telling you your code length measurements
were bunk. What's the deal, Jon Harrop?
What's the deal?
Bill Atkins <············@rpi.edu> writes:
> Jon Harrop <······@jdh30.plus.com> writes:
>
> > [...]
> >
> > Anyway, the ray tracer is only meant to be a little fun.
>
> Is it really? I first came to Lisp last May, and even then you were
> filling comp.lang.lisp/comp.lang.scheme with these silly benchmarks
> and even then people were telling you your code length measurements
> were bunk. What's the deal, Jon Harrop?
I think Jon Harrop gets more flak that he deserves. Quite a lot of the
criticism that was levied against his benchmarks was justified, but Jon also
did eventually incorporate quite a lot of the constructive criticism.
The task is neither so simple as to be entirely without interest nor so
complex as to be completely unintelligible.
And whilst it is certainly true that only quite limited conclusions about the
suitability and performance of various languages for real world tasks can be
drawn from a small toy example like this raytracer, I think those who conclude
that this benchmark is consequently completely useless are overshooting the
mark (it's not like vastly better data of this kind would be widely available
or idiomatically implementing the specific task one is actually interested in
in all these languages for comparison would be practical in most situations).
If nothing this page serves as a nice example of how to optimize a certain
type of code in various languages and to what extent clarity and conciseness
are traded off against performance in the process. I'm looking forward to
seeing further improvements to this benchmark and similar benchmarks for tasks
that stress different language features in the future.
And yes, consecutive whitespace should not play a role in verbosity measures.
'as
It is easy to lie with statistics, but it's a lot easier to lie without them.
-- Richard J. Herrnstein
Juho Snellman wrote:
> bradb <··············@gmail.com> wrote:
>> But yes, in this floating point intensive example, Lisp (at least SBCL)
>> gets beaten like a red-headed stepchild.
>
> It's not a fp intensive test, but more of a garbage collection
> benchmark.
SBCL-compiled Lisp is very GC-bound. The other languages are not.
> It would be significantly faster in newer SBCL versions.
I've just installed 0.9.9 and it is significantly faster for the more
GC-intensive versions (e.g. down from 69s to 45s) but is significantly
slower for the fastest version (e.g. up from 36s to 50s). I'll update the
results ASAP.
> It
> would be significantly faster if the damage that Dr. Harrop has
> inflicted on the Lisp code were undone.
Can you be more specific? I do not have any other Lisp implementations that
are significantly faster but I'll gladly publish any improvements that
people can make, verbatim for the fifth version.
> Or it could be made faster
> still with a bit of simple macrology, which Dr. Harrop is unable to
> replicate in other languages, and is apparently therefore an unfair
> optimization.
Unboxing is easily replicated in other languages. Indeed, there are now
fifth implementations that have this optimisation. Lisp does substantially
better in terms of performance but substantially worse in terms of code
size. Other languages see a similar shift, to higher performance and worse
verbosity. In theory, Lisp may do asymptotically better than macro-less
languages but, in practice, I'm not sure.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> wrote:
> Juho Snellman wrote:
>> It would be significantly faster in newer SBCL versions.
>
> I've just installed 0.9.9 and it is significantly faster for the more
> GC-intensive versions (e.g. down from 69s to 45s) but is significantly
> slower for the fastest version (e.g. up from 36s to 50s).
I find that very hard to believe.
But then again, several of your other timings also look horribly
wrong. There's no way compiling any of the programs in SBCL is taking
8 seconds, considering the hardware. And there's no way the slowest
Lisp implementation is taking 40x as long as the fastest Ocaml
version.
>> It
>> would be significantly faster if the damage that Dr. Harrop has
>> inflicted on the Lisp code were undone.
>
> Can you be more specific?
Sure. Your version of code (4/ray.lisp) no longer inlines some
critical functions. Just fixing this would give a 50% speedup. In
general, your lack of CL experience is pretty obvious. The code looks
like it was formatted with Notepad, the new additions are written in
horrible CL style, and at places reimplement standard CL functionality
(badly).
Here's a version of 4/ray.lisp, with the above issues fixed. Since you
seemed to consider code "littered with type declarations" to be
inappropriate, I've removed practically all of them (with little
performance effect; SBCL could infer most of them, the remaining ones
were not in hot spots):
<http://jsnell.iki.fi/tmp/new4.lisp>
Here's a version of the above that with unboxed vector arithmetic:
<http://jsnell.iki.fi/tmp/mv4.lisp>
Now, I know I'm probably just wasting my breath, but your VERBOSITY
METRIC STILL SUCKS. Why can't you just use something that ignores the
effect of source code formatting, as has been requested several times?
Like bytes, ignoring leading whitespace? Or counting multiple adjacent
characters of whitespace as one?
Here, I'll make it really easy for you:
perl -0ne 's/\s+/ /g; print length, "\n"' filename
--
Juho Snellman
Juho Snellman wrote:
> But then again, several of your other timings also look horribly
> wrong. There's no way compiling any of the programs in SBCL is taking
> 8 seconds,
I am getting compile times of around 4s with SBCL 0.9.9.
> considering the hardware.
I'm running an AMD64 at 800MHz.
> And there's no way the slowest
> Lisp implementation is taking 40x as long as the fastest Ocaml
> version.
The first implementations are intended to be clear. Consequently, I removed
the type declaration and inlining optimisations from the Lisp. With 0.9.9,
the Lisp is only 19x slower than the fastest OCaml.
I may add a 0th implementation that is to be as short as possible
(obfuscation competition), just for fun.
>> Can you be more specific?
>
> ... The code looks like it was formatted with Notepad, ...
Emacs.
> Here's a version of 4/ray.lisp, with the above issues fixed. Since you
> seemed to consider code "littered with type declarations" to be
> inappropriate,
Such type declarations are an unnecessary source of verbosity.
> I've removed practically all of them (with little
> performance effect; SBCL could infer most of them, the remaining ones
> were not in hot spots):
> <http://jsnell.iki.fi/tmp/new4.lisp>
Thank you. This 124-LOC program runs in 31.893s making it significantly
shorter and faster than the previous 4th Lisp implementation.
> Here's a version of the above that with unboxed vector arithmetic:
> <http://jsnell.iki.fi/tmp/mv4.lisp>
This 198-LOC program runs in 16.565s, making it much faster than the other
Lisp implementations but much more verbose than any other implementation.
> Now, I know I'm probably just wasting my breath, but your VERBOSITY
> METRIC STILL SUCKS. Why can't you just use something that ignores the
> effect of source code formatting, as has been requested several times?
> Like bytes, ignoring leading whitespace? Or counting multiple adjacent
> characters of whitespace as one?
>
> Here, I'll make it really easy for you:
> perl -0ne 's/\s+/ /g; print length, "\n"' filename
I have included non-whitespace character counts now. As you can see, the
results are not affected.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> wrote:
> Juho Snellman wrote:
>> But then again, several of your other timings also look horribly
>> wrong. There's no way compiling any of the programs in SBCL is taking
>> 8 seconds,
>
> I am getting compile times of around 4s with SBCL 0.9.9.
Interesting. Looks like something was indeed wrong with the old
results, since the 8x difference between OCaml and SBCL is now just a
3x difference.
(The changes to the Lisp environment don't explain this change. The
compilation speed difference between 0.9.4 and 0.9.9 is on the order
of 5%, and the new Lisp code actually takes 2x *longer* to compile
than the old one. So the old result was actually somehow off by a
factor of 4.)
>> And there's no way the slowest
>> Lisp implementation is taking 40x as long as the fastest Ocaml
>> version.
>
> The first implementations are intended to be clear. Consequently, I removed
> the type declaration and inlining optimisations from the Lisp.
Ok. No such changes had been made in the first version as of two days
ago, which is why the claim looked pretty unlikely...
> With 0.9.9, the Lisp is only 19x slower than the fastest OCaml.
I'm not really convinced that removing something as simple as
(declaim (inline vec *v +v -v dot magnitude unitise ray-sphere intersect
ray-trace))
is really justified on the basis of clarity. This is fundamentally a
performance benchmark, and the inlining by itself makes a 3-4x
difference. But it's your show.
>>> Can you be more specific?
>>
>> ... The code looks like it was formatted with Notepad, ...
>
> Emacs.
In that case you're probably using a mode for some other Lisp dialect,
or there's some other configuration issue. For example in the parts
for 1/ray.lisp that you've edited, the indents for IF,
MULTIPLE-VALUE-BIND, and LABELS are wrong.
> I have included non-whitespace character counts now. As you can see, the
> results are not affected.
Thanks!
I disagree about it having no effect on the results. For example,
let's take all 24 programs, and rank them according to each of the
metrics. Here's the average rank of the 4 programs for each language:
lines bytes no-ws tokns
cpp: 14.50 13.75 17.75 17.25
java: 18.25 15.75 17.50 15.75
lisp: 13.25 19.75 11.50 9.00
ml: 2.75 3.00 3.25 2.75
sc: 20.00 16.00 16.25 20.25
sml: 6.25 6.75 8.75 10.00
Whether whitespace is counted or not affects the average rank of C++
programs by 4 places and of Lisp programs by *8.25* places. Using
lines instead of bytes affects the average rank of Scheme programs by
4 places and of SML programs by 2.5 places.
[ I've defined tokens as follows: Whitespace characters are not
tokens. Each single non-alphanumeric character is one token. Each
sequence of adjacent alphanumeric character is one token. This seems
like a reasonable approximation. I've included the token-counting
mainly as illustration, I'm not arguing that this particular way
would necessarily be better than measuring non-whitespace bytes. ]
Or alternatively, consider the average normalized size (smallest
program by each metric has size 1, largest one size 2) of the programs
in each of the languages:
lines bytes no-ws tokns
cpp: 1.68 1.57 1.76 1.68
java: 1.80 1.63 1.76 1.63
lisp: 1.61 1.78 1.50 1.42
ml: 1.15 1.14 1.17 1.13
sc: 1.85 1.63 1.73 1.81
sml: 1.31 1.30 1.40 1.42
Again, the different metrics give significantly different results.
--
Juho Snellman
Juho Snellman wrote:
> Interesting. Looks like something was indeed wrong with the old
> results, since the 8x difference between OCaml and SBCL is now just a
> 3x difference.
I've switched to timing compilation of the fourth implementations rather
than the first implementations, to get slightly more meaningful results.
Some of the compilers run at almost exactly the same speed (e.g. MLton) and
others now run substantially slower (e.g. OCaml).
> (The changes to the Lisp environment don't explain this change. The
> compilation speed difference between 0.9.4 and 0.9.9 is on the order
> of 5%, and the new Lisp code actually takes 2x *longer* to compile
> than the old one. So the old result was actually somehow off by a
> factor of 4.)
OCaml has also changed and it is no longer the fastest compiler. Also, my
previous SBCL installation was compiled from source whereas my new one was
a binary.
>> The first implementations are intended to be clear. Consequently, I
>> removed the type declaration and inlining optimisations from the Lisp.
>
> Ok. No such changes had been made in the first version as of two days
> ago, which is why the claim looked pretty unlikely...
I think I messed up uploading the code so it was wrong for a few days. I
think it is correct now though. I have also automated much of the measuring
process so there should be fewer errors in the future.
> I'm not really convinced that removing something as simple as
>
> (declaim (inline vec *v +v -v dot magnitude unitise ray-sphere intersect
> ray-trace))
>
> is really justified on the basis of clarity. This is fundamentally a
> performance benchmark, and the inlining by itself makes a 3-4x
> difference. But it's your show.
This is not "fundamentally a performance benchmark" at all. The initial
versions (particularly the first) are about simplicity. This is clearly
stated on the page: "This comparison is as much about simplicity as it is
about performance".
The faster, later implementations clearly deserve such low-level
optimisations, of course.
> I disagree about it having no effect on the results. For example,
> let's take all 24 programs, and rank them according to each of the
> metrics. Here's the average rank of the 4 programs for each language:
>
> lines bytes no-ws tokns
> cpp: 14.50 13.75 17.75 17.25
> java: 18.25 15.75 17.50 15.75
> lisp: 13.25 19.75 11.50 9.00
> ml: 2.75 3.00 3.25 2.75
> sc: 20.00 16.00 16.25 20.25
> sml: 6.25 6.75 8.75 10.00
>
> Whether whitespace is counted or not affects the average rank of C++
> programs by 4 places and of Lisp programs by *8.25* places. Using
> lines instead of bytes affects the average rank of Scheme programs by
> 4 places and of SML programs by 2.5 places.
Why disregard quantitative information in favour of rankings when you can
just look at the graph and clearly see that OCaml is both faster and more
concise than all of the implementations in all other languages except the
fastest C++, which is only ~10% faster?
I see the data a different way - assume you can interpolate between the
different implementations for each language, any other languages with all
implementations lying either entirely to the left (slower) or above (more
verbose) are not preferable for this task.
Java, 32-bit C++ and SBCL Lisp are all similarly undesirable, as the slowest
and most verbose languages.
SML/NJ gives similar performance but is significantly more concise.
MLton is significantly faster and more concise than all of the above
languages and Stalin Scheme and 64-bit C++ are faster with similar brevity.
64-bit OCaml is both faster and more succinct that all of the other
languages on this benchmark except 64-bit C++ which can be slightly faster.
> [ I've defined tokens as follows: Whitespace characters are not
> tokens. Each single non-alphanumeric character is one token. Each
> sequence of adjacent alphanumeric character is one token. This seems
> like a reasonable approximation.
Is this counting almost all of the arithmetic operators (+., *., +|, *|
etc.) in OCaml as 2 tokens each? What about ->, => etc.?
> Or alternatively, consider the average normalized size (smallest
> program by each metric has size 1, largest one size 2) of the programs
> in each of the languages:
>
> lines bytes no-ws tokns
> cpp: 1.68 1.57 1.76 1.68
> java: 1.80 1.63 1.76 1.63
> lisp: 1.61 1.78 1.50 1.42
> ml: 1.15 1.14 1.17 1.13
> sc: 1.85 1.63 1.73 1.81
> sml: 1.31 1.30 1.40 1.42
>
> Again, the different metrics give significantly different results.
That is better than using rankings but those results don't look
significantly different to me: For all measures of verbosity, OCaml is most
concise and SML is second most concise. C++, Java, Lisp and Scheme are just
fighting for last place in the verbosity stakes but 64-bit C++ is vastly
faster than Java, Lisp and Scheme so C++ still has a use here.
Combine that with the fact that OCaml beats Lisp, Scheme and Java on both
performance and compile time and you can draw a conclusion...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
>
> Combine that with the fact that OCaml beats Lisp, Scheme and Java on both
> performance and compile time and you can draw a conclusion...
>
Ignoring verbosity, SCBL is a better choice on my lowly 32 bit machine
that Ocaml. The Ocaml compiler obviously really likes 64 bit code, as
the 32/64 speedup is extremely pronounced.
Brad
bradb wrote:
>> Combine that with the fact that OCaml beats Lisp, Scheme and Java on both
>> performance and compile time and you can draw a conclusion...
>
> Ignoring verbosity, SCBL is a better choice on my lowly 32 bit machine
> that Ocaml. The Ocaml compiler obviously really likes 64 bit code, as
> the 32/64 speedup is extremely pronounced.
Yes. G++ also does a vastly better job in 64-bit.
You've reminded me of another point though - how different are the results
on Intel hardware rather than AMD? I think most of the compilers are
roughly as good but, in particular, OCaml is significantly worse and SBCL
is significantly better on Intel hardware (IIRC).
I'll try to upload a benchmark suite, so people can rerun the whole thing
themselves easily...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
"Jon Harrop" <······@jdh30.plus.com> wrote in message
·····························@ptn-nntp-reader02.plus.net...
> Juho Snellman wrote:
>> I disagree about it having no effect on the results. For example,
>> let's take all 24 programs, and rank them according to each of the
>> metrics. Here's the average rank of the 4 programs for each language:
>>
>> lines bytes no-ws tokns
>> cpp: 14.50 13.75 17.75 17.25
>> java: 18.25 15.75 17.50 15.75
>> lisp: 13.25 19.75 11.50 9.00
>> ml: 2.75 3.00 3.25 2.75
>> sc: 20.00 16.00 16.25 20.25
>> sml: 6.25 6.75 8.75 10.00
>>
>> Whether whitespace is counted or not affects the average rank of C++
>> programs by 4 places and of Lisp programs by *8.25* places. Using
>> lines instead of bytes affects the average rank of Scheme programs by
>> 4 places and of SML programs by 2.5 places.
>
> Why disregard quantitative information in favour of rankings when you can
> just look at the graph and clearly see that OCaml is both faster and more
> concise than all of the implementations in all other languages except the
> fastest C++, which is only ~10% faster?
Fine, but anyone who agrees that a measure of consiseness should say that
if (test)
{
true;
}
else
{
false;
}
test?true:false;
(IF (test)
(true)
(false))
test IF true ELSE false THEN
are different has to be an abomidable typist. My typing speed goes way
down when I'm writing code because I'm thinking about what I'm creating,
so the time it takes to write an if statement is minimal. As far as I'm
concerned, ALL the above are equivalent in consiseness, so a line or
byte count test is worse than useless.
--
Geoff
Geoffrey Summerhayes wrote:
> Fine, but anyone who agrees that a measure of consiseness should say that
>
> if (test)
> {
> true;
> }
> else
> {
> false;
> }
>
> test?true:false;
>
> (IF (test)
> (true)
> (false))
>
> test IF true ELSE false THEN
>
> are different has to be an abomidable typist. My typing speed goes way
> down when I'm writing code because I'm thinking about what I'm creating,
> so the time it takes to write an if statement is minimal. As far as I'm
> concerned, ALL the above are equivalent in consiseness, so a line or
> byte count test is worse than useless.
I read my code more often than I write it (whilst developing), so I think it
is more important to be able to read it quickly. If you can get more on one
line then you can read it more quickly (IMHO), so I still prefer LOC to
non-whitespace bytes. However, I don't think the results are significantly
different anyway.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
"Jon Harrop" <······@jdh30.plus.com> wrote in message
·····························@ptn-nntp-reader04.plus.net...
>
> I read my code more often than I write it (whilst developing), so I think
> it
> is more important to be able to read it quickly. If you can get more on
> one
> line then you can read it more quickly (IMHO), so I still prefer LOC to
> non-whitespace bytes. However, I don't think the results are significantly
> different anyway.
IYCRTYABMTIA.
--
Geoff
Geoffrey Summerhayes wrote:
> "Jon Harrop" <······@jdh30.plus.com> wrote in message
> ·····························@ptn-nntp-reader04.plus.net...
> > If you can get more on one
> > line then you can read it more quickly (IMHO), so I still prefer LOC to
> > non-whitespace bytes.
>
> IYCRTYABMTIA.
If you can read this, you are (a) bigger masochist than I am.
??
j.k. wrote:
> Geoffrey Summerhayes wrote:
> > "Jon Harrop" <······@jdh30.plus.com> wrote in message
> > ·····························@ptn-nntp-reader04.plus.net...
> > > If you can get more on one
> > > line then you can read it more quickly (IMHO), so I still prefer LOC to
> > > non-whitespace bytes.
> >
> > IYCRTYABMTIA.
>
> If you can read this, you are (a) bigger masochist than I am.
>
> ??
Some people are just too damn smart for my own good... :-)
The point being conciseness and clarity don't always go hand-in-hand.
--
Geoff
Geoffrey Summerhayes wrote:
> The point being conciseness and clarity don't always go hand-in-hand.
Indeed, but I don't think translating to the Lisp makes this particular
example any clearer:
(I(Y(C(R(T(Y(A(B(M(T(I(A))))))))))))
;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
"Jon Harrop" <······@jdh30.plus.com> wrote in message
·····························@ptn-nntp-reader02.plus.net...
> Geoffrey Summerhayes wrote:
>> The point being conciseness and clarity don't always go hand-in-hand.
>
> Indeed, but I don't think translating to the Lisp makes this particular
> example any clearer:
>
> (I(Y(C(R(T(Y(A(B(M(T(I(A))))))))))))
>
> ;-)
True, but by your metric, it's aces. There are other problems
as well, consiseness in source does not guarantee either
consiseness in machine code or speed. I've seen several
examples in C where the longer source generated shorter,
faster code. The other has a lot to do with the way we read.
Remember the old:
There are two
errors in the
the title of
this book.
To put it another way, it's easier to hide an elephant in
dense bush than an open field. I find an error easier to find
if it's out in the open on its own line, rather than buried
inside a line doing multiple things at once.
Also, as I mentioned in another thread I use superfluous
parentheses in C code to indicate precedence because it's
easier to parse and I hate having to stop and rethink each
one to see if I made a ordering mistake when looking for a
bug, the semi-infamous *a++, for example.
All of which makes the code worse by your metric. I guess I
suck as a programmer. :(
--
Geoff
On 2006-03-10, Jon Harrop <······@jdh30.plus.com> wrote:
> I read my code more often than I write it (whilst developing), so I think it
> is more important to be able to read it quickly. If you can get more on one
> line then you can read it more quickly (IMHO), so I still prefer LOC to
> non-whitespace bytes. However, I don't think the results are significantly
> different anyway.
So, (sorry if I've missed your comments on this before), what do you
think about this in relation to the translations of your ray tracer into
J and K?
(I find that tokens (not a strict definition as a lexer would use, but
rather more like "words") to be the best count -- dense lines and few
lines of code are harder to read than spare lines and more lines of
code, but all in moderation.)
--
Julian Squires
Julian Squires wrote:
> So, (sorry if I've missed your comments on this before), what do you
> think about this in relation to the translations of your ray tracer into
> J and K?
I have not yet found the time to study the ray tracer's in J or K but the
brevity is amazing. Moreover, I believe the performance is comparable to
that of Lisp.
> (I find that tokens (not a strict definition as a lexer would use, but
> rather more like "words") to be the best count -- dense lines and few
> lines of code are harder to read than spare lines and more lines of
> code, but all in moderation.)
I am sure J and K will easily beat all of the current languages using any of
the verbosity metrics. Once I get the environments up, I'll add J and K to
the list of languages...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
funkyj wrote:
> Also, what is the secret of Stalin's success? Perhaps SBCL can be
> converted to despotism and reap similar rewards.
I don't like the scheme dialect Stalin defines because it lacks
numbers bigger than 64 bits and it has what I consider "broken"
error handling - ie, you can add two positive numbers and get a
negative result. No error signalled, no error-result returned,
no coercion to floating-point; nothing.
That said, however, I admire the heck out of the compiler. It
is one of the most aggressive optimizing compilers anywhere for any
language. It eliminates typechecks given very few declarations,
and it also eliminates most consing and collection where possible
with intensive liveness analysis. It transforms algorithms by
caching results of functional algorithms, and does aggressive
inlining, constant propagation, etc.
I think most of the techniques are usable for Common Lisp, but it'd
be a lot of work.
Bear