Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!trib.apple.com!amd!netcomsv!torii!kirk
From: kirk@triple-i.com (Kirk Rader)
Subject: Re: C is faster than lisp (lisp vs c++ / Rick Graham...)
Message-ID: <CvvGsB.2AG@triple-i.com>
Sender: usenet@triple-i.com
Nntp-Posting-Host: pak+
Organization: Information International Inc., Culver City, CA
References: <Cv9q23.89q@cogsci.ed.ac.uk> <CvEMGF.570@triple-i.com> <Cvo0E7.Gws@cogsci.ed.ac.uk>
Date: Fri, 9 Sep 1994 17:04:58 GMT
Lines: 265

In article <Cvo0E7.Gws@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

[...]

I used the word disingenuous in the following sense (quoting from
Merriam's New Collegiate Dictionary 1981 edition):

"disingenuous - lacking in candor; also: giving a false appearance of
simple frankness : CALCULATING" [capitalization in the source.]

>No, that's not it.  I accused you of responding as if I'd considered
>only the parts I quoted.  And you in fact did just that, or something
>very near.  You even accuesed me of quoting out of context, though
>neither you nor anyone else (on comp.lang.lisp or in e-mail -- hint
>to some who've e-mailed me) has offered anything I quoted that means
>something different in context.  If someone ever does, I will be 
>glad to retract what I said and apologize.

But by leaving out the surrounding statements which modified and
softened the position I was taking, it seemed to me that you gave the
appearance of my taking positions stronger and ultimately with a
different meaning than those I in fact did.  You then responded to the
arguments it seemed that you had carefully constructed the appearance
of my making, rather than the arguments I in fact made.  Also, you
failed to include or take account of the fact that all of the
strong-sounding statements you quoted were in the context of concrete
examples of specific applications where I had concluded from
experience that lisp was worse suited than C, while leaving out the
passages that acknowledged that for other kinds of applications I feel
that the opposite result holds.  Thus it seemed to me that you made it
appear as if I were stating general principles about all languages or
all kinds of applications that I never, in fact, made.

>For it may that I've misunderstood you.  That's entirely possible.
>But I'm not deliberately distorting what you say, and I'm not being
>disingenuous.

I accept what you say.  But can you understand from the above why I
have felt at times that you may have been?

[...]

>That may be, but there must be better ways to straighten such things out.
>At this point, we are both reacting w/ excess hostility, it seems to me.

I agree.

>As for relevance, I am sometimes trying to counter impressions rather
>than to refute your points.

But by leaving out or belittling the aspects of my own messages which
acknowledge lisp's strengths and explicitly state my real belief that
lisp is better suited to many tasks than languages like C, it seems to
me that you have reinforced the negative impression rather than
diminished it.

>Well, I don't think it's _only_ a misunderstanding.  There seem to
>be genuine disagreements as well.

[...]

Absolutely.  But I am of the impression that we actually agree on more
than we disagree, and that the areas of disagreement are hardly worth
the amount vitriol we have both expended.

>----------------------------------------------------------------------
>
[...]

>Now, why do you find it so important to make all these points about
>Lisp rather than about particular Lisp-family languages and particular
>implementations?  Why spend all this time and effort?  What's so
>bad about someone saying Lisp needn't ever be too large or slow
>and *getting away with it*?  Especially since very strong points
>can be made about current implementations and the ones that are
>likely to be available in the near future.

I think that our disagreement here is mainly a matter of our each
having perceived a different "spin" to this thread.  I have never
perceived myself to have been, and have several times specifically
disavowed, making theoretical claims about all possible lisp dialects.
I have consistently tried to make it clear that I have been talking
about practical programming issues using real-world lisp
implementations for real-world programming projects _today_.  I use
the word "lisp" rather than "Acme Common Lisp" or "Joe's Shareware
Scheme" both because I wish to make it clear that I am not talking
about issues relevant to just one implementation but to features that
all current implementations seem to share, and because I do not think
that it would be fair to any particular vendor to give the appearance
of singling them out as being particularly bad at some given task when
in fact the issues I have raised are equally applicable to their
competitors.

[...]

>Programming languages don't line up neatly with application areas,
>and when people try to line them up they often get it wrong.
>
>Moreover, there's little point in concluding that Lisp will be worse
>than C *somewhere* (though we don't know where).  We need to have an
>idea of where and how much worse and what scope there is to make Lisp
>do better.  So this general point about "natural aptitude" doesn't
>tell us anything very useful even if it were completely correct.

But why do you assume I have gotten it wrong?  I have tried to give
concrete examples of areas (e.g. GC being a poor choice of
memory-management for a particular kind of application which makes
few-in-number-but-large-in-size dynamic allocations) where it has been
demonstrated sufficiently to satisfy me that C's features (malloc /
free) are better suited than lisp's (make-array / GC).  But this isn't
a matter of "application areas" in the sense I think you mean but
rather a matter of specific application requirements, (although it is
true that in many application areas, most or all applications'
requirements will have a family resemblance.)

[...]

>But I (at least) don't argue about which language is better in
>an absolute sense.  (Just in case this wasn't clear.)

I wasn't accusing you of doing so.  I was trying to clearly restate
what _my_ position is.

[...]

>That is again not a position I hold.  (I'm again trying to counter
>possible confusions and misunderstandings just in case they exist.)

Again, I was stating _my_ position without reference to yours.

[...]

>Well, why *did* you say those other things?  Presumably you did
>feel Lisp, and not just particular implementations, had problems
>with I/O; that higher-level features necessarily had costs; and
>so on.

I do feel that lisp, i.e. the family of languages commonly regarded as
lisp dialects, does have as a group certain features that makes it
well suited to certain tasks and ill suited to others.  I do feel that
higher-level features necessarily have costs, with the specific
stipulation that it is possible to have trivial additional features or
purely syntactic conveniences with so little extra cost that they can
be regarded as free.  I do not put any of the features to which I have
been referring in that "trivial" category, however.  And that the cost
of supporting some additional feature may in particular instances be
more than outweighed by the benefits that it confers does not make it
free.  It does mean that sometimes it is worth trading off some
incremental increase in size or decrease in performance in one area so
as to obtain some advantage in another.  The higher-bandwidth
allocations and deallocations that are the result of using GC traded
off against the fact that, in general, where there is a GC there will
also be garbage is an example of a feature which can either benefit or
hurt an application depending on its requirements and design.

[...]

>Then why didn't you confine yourself to facts instead of including
>not-fully-justified claims about Lisp in general and making _a priori_
>arguments about higher-level features?

I disagree with your characterization of my arguments.

>Look, this is not, especially now, some kind of coded accusation or
>claim about your real aims.  I don't know why you said many of the
>things you did, especially since you could -- and did -- offer much
>stronger arguments on narrower, less inflamatory, claims.  Moreover, 
>I don't understand why you think I shouldn't pay any attention to
>these other points.

[...]

I don't think that you "shouldn't pay any attention to these other
parts."  I disagree with your interpretation of them.  If that is
because I haven't expressed myself clearly enough, then that is my
fault but I do not know how to express myself more clearly so I
suggest that we simply stop arguing in circles around one another, and
agree to disagree (where we do.)

>I think what you've said may have that effect (discouraging people
>from using Lisp) and may well reinforce a number of prejudices besides.

If that is the case, it was not my intention.

>I suspect that most people think Lisp is well-suited to some things.
>That doesn't say very much in itself.  When I point out that Lisp
>could do much better, that current implementations are misleading,
>etc, you don't agree with me.

But I _have_ agreed.  What I have objected to was what seemed to me to
be responses to a different argument than one which I was making.  I
have never disputed that lisp implementations could be different than
they are now, perhaps making them better suited to some of the tasks
at which I consider them presently to be rather poor.  But I have
never been talking about programming language theory, rather about
application programming practice (which I consider as valid a topic of
discourse for comp.lang.lisp.)  In addition, (and here _is_ a
substantive point of disagreement between us, I think) even from a
theoretical point of view I seriously question the assumption that
these future hypothetical lisp implementations could both be
well-suited to the kinds of applications to which C is currently
better suited _and_ still be well-suited to the kinds of applications
for which lisp is currently better suited.  I am willing to be shown
how they could, but I have seen no arguments that have convinced me
that it is even plausible.

>                              Nor do you (at least no so far)
>say just how bad the problems you've observed are.  You give the
>impression that they're so bad as to disqualify Lisp, but for
>all we know Lisp is only 10% slower than C or the problems are
>due to poorly tuned implementations.

It is true that I have not presented, and do not feel it necessary or
appropriate to present, the output of specific analytical tools.  I
have recommended that people use such tools on their own applications
to test whether or not they are suffering similar sorts of performance
problems.  I have stated that I do in fact consider that lisp has been
disqualified for certain applications on the basis of such analyses.
While I have observed differences in performance much greater than
10%, even 10% (or less) can make the difference between acceptable
performance and unacceptable performance for certain kinds of
applications.  Such criteria are so application specific that I do not
feel that it is useful or meaningful to even try to go into the level
of detail on which you seem to insist.

>                                      (That a number of different
>Lisps have the same problem shows very little, BTW.)

It shows that lisps in general and not just some particular
implementation have problems for the kinds of applications to which I
have referred.

[...]

>
>I think it's counterproductive to engage in that kind of psychological
>speculation/analysis: not only are they wrong, they're over-compensating
>for a mistaken perception and *pretending* that the facts are different
>than they are.  --  You must know how annoying and insulting that will
>be.

You have no idea how annoying and insulting I have found most of your
messages?

>Anyway, just what tasks *are* those at which Lisp is really bad?  
>And just how bad is it?  Will you now say?
>
>-- jeff

Since you ask, I will again repeat the kinds of tasks I feel lisp to
bad at: real-time tasks and system- or application-level tasks that
are not "real-time" in the traditional sense but which require
continuous high-bandwidth interaction with hardware or the user.  And
let me again point out that I only think that lisp is bad in those
instances where the requirements of the application are at odds with
the design and implementation of the language.  It may be possible
that some application that falls into the above categories actually
would benefit from some current or future lisp's memory-management
philosophy and other features, but I have yet to encounter one.  As
for "how bad", all that I can meaningfully say without going into much
greater detail than I am prepared to about the design and
implementation of the specific applications on which I have worked is
"bad enough".

Kirk Rader
