Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: C is faster than lisp (lisp vs c++ / Rick Graham...)
Message-ID: <Cw35tA.8AE@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <Cvo0vJ.Kwu@triple-i.com> <CvqDDB.1FA@cogsci.ed.ac.uk> <Cw0uK3.HLz@triple-i.com>
Date: Tue, 13 Sep 1994 20:48:45 GMT
Lines: 166

In article <Cw0uK3.HLz@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <CvqDDB.1FA@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>In article <Cvo0vJ.Kwu@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>>>In article <CvGIz3.FsJ@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>>>>Just when I think the discussion may have taken a reasonable turn,
>>>>I get this.
>>>>
>>>>I hope that some day comp.lang.lisp is used to discuss how Lisp can be
>>>>improved for applications where it performs poorly now rather than why
>>>>such attempts are bound to sacrifice features or irritate Lisp "purists".
>>>
>>>[...]
>>>
>>>How lisp can be improved is one valid use for comp.lang.lisp.  Another
>>>valid use is in requesting and offering advice on how to use lisp, or
>>>how to avoid the potential problems one might encounter in using it.
>>
>>Something I have never disagreed with.
>>
>>However, it helps to get it right.
>
>That is, obviously, a matter of point of view.  I believe myself to
>have "gotten it right" and have received any number of private email
>messages indicating that some people, at least, agree that I have done
>so.  I don't doubt that you have received the same in support of you
>positions -

But I do doubt it.  I have received exactly one.

> so simply making this sort of unsupported assertion that

So I have to repeat the support in every article?

BTW, when in this have you offered advice on how to avoid potential
problems?  What you've said is Lisp is unsuitable.

>I'm wrong does nothing but exacerbate the ill-will in this thread that
>I though we each were making efforts to ameliorate.

I don't have any ill will towards you personally, but for some
reason the line you took in the message I was answering really
annoyed me.

Anyway, I will also make a "point of view" remark.  What we're really
told in about Lisp and applications is not that Lisp is right (or
wrong) for application X but that some person (not always you) finds 
it so.  That's why I want enough information to be posted so that
everyone can make up their own minds.  What are the costs?  
What would have to change in the Lisp implementation to reduce
them?  And so on.

Compare this thread to the one on "data bloat".  There, the problem
was quantified, and various ways to reduce discussed.  That's the
kind of critical thread I'd like to see.  This one is just frustrating
and annoying.

>>>One such request for information and advice came, and the response
>>>amounted to "criticisms of lisp as being too big or too slow are all
>>>just lisp bashing."  I responded that this was not true and that for
>>>some kinds of applications the costs of using lisp outweigh its
>>>benefits, while explictly stating that for other applications the
>>>opposite is true, so that care should be taken when choosing a
>>>language. 

I believe that I could have made that point without seeming to suggest
anything more general, or could quickly have amended my presentation.
Since I do not believe that I am especially skilled at such things, I
have to believe that you could do so as well.  It seems to me that you
think Lisp will inherently have problems in certain application areas
and not just that implementations currently have such problems.
For otherwise, I am baffled as to why you said anything along those
lines at all.

>>>        _You_ were the one who chose to interpret this as some sort
>>>of general denunciation of all possible lisp dialects, past or future.
>>>Use whatever rhetorical devices you wish, but I believe my position in
>>>this has been more moderate and reasonable than yours.

>>Bull.  You introduced claims about inherent problems of Lisp
>>and you offered _general_ arguments about the costs of richer
>>semantics.
>
>Again: _only in the context of a discussion of application-specific
>performance issues_.

But about *Lisp*, not about particular implementations.  Is it
still not clear that that's what's at issue here?  I know you
don't say Lisp loses for *all* applications.  That was never
in dispute!

>  When people have suggested that my remarks could
>be interpreted as making more general claims I have repeatedly both
>agreed that it is possible, though not currently common-place, to deal
>with these issues via language design and implementation and pointed
>out that the appearance of my even making such general claims was (I
>still believe) mainly the result of selective quoting out of context.

What did they mean in context that was different?  How does (for
instance) the following not mean what I take it to mean, namely that 
*Lisp* has unavoidable problems and that higher-level features 
(unless "trivial") have them as well?

  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.

If the problems were avoidable, how could Lisp be ill suited?
It would be only languages and implementations that failed to
avoid the problems that were ill suited.

>Having said all that, I still have seen no convincing argument from
>you on how you think it possible that a language could both retain a
>significant percentage of the additional features of present lisps and
>also be suitable for a significant percentage of the kinds of
>applications for which present lisps are not well suited.  Until I see
>any such convincing arguments, I will persist in my belief that
>additional features don't come for free.

So how have I distorted what you've said?

Now the simple fact is that a number of past and current Lisps have
retained a significant fraction of the usual features of Lisp while
becoming suitable for a much greater range of applications.  I see
no reason why that cannot continue.  There may be limits, but why
suppose we can say now what they are?

Moreover, no one Lisp has to do everything, and a number of
features of current Lisps (esp Common Lisp) could well be
dropped.

I am not claiming Lisps *are* suitable for anything they're not
suitable for.  But you are claiming (or persisting in the belief
that) they cannot be.  You haven't shown that to be so or how
great the cost will be.  You won't even say how great are the
costs you've observed.  Moreover, you've done nothing to show
it will be difficult to avoid the cases that are "expensive"
when it's necessary to do so.

My arguments are all aimed at leaving open possibilities that are
in fact open.  There's nothing more that I've claimed or need
to prove (apart from the meta-junk which I hope we can eventually
drop).

>I have never said that there is _no_ real disagreement between us.
>I do think that the substantive issues on which we disagree are not
>worth the length or heatedness of this thread, and have proposed
>ending it any number of times.  I am not willing, however, to simply
>let this sort of message stand unanswered.

And I am not willing to let it stand that the behavior of
current implementations tells us what's possible for Lisp,
because it's not true.

BTW, I know of a number of applications for which all Lisps I've
looked at (a great many) are unsuitable.

-- jd

PS I'll try to answer you're longer article with less heat,
but the dictionary quoting at the start was more than I could
face today.

