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!math.ohio-state.edu!jussieu.fr!univ-lille1.fr!zaphod.crihan.fr!warwick!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: <CvGIz3.FsJ@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: <CuzxyG.6v2@triple-i.com> <Cv3vu4.C03@cogsci.ed.ac.uk> <CvB285.6Lz@triple-i.com>
Date: Thu, 1 Sep 1994 15:28:14 GMT
Lines: 102

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".

In article <CvB285.6Lz@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <Cv3vu4.C03@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
>
>[...]
>
>>It's hard to draw conclusions about Lisp in general.  I'm not trying
>>to quibble about the meaning of "Lisp".  
>
>It seems to me that is exactly what you are doing.

But every time you say what I include in "Lisp" you get it wrong,
supposing that I mean something ridiculously inclusive that I can
exploit to reach absurd conclusions.

Sure, *you* interpret me that way, but its not what I'm doing.

Lisp is not confined to existing languages and implementations.  What
I've said about possibilities is based on existing or past Lisps, on
trends neglected while the 80s "big Lisps" ruled, on the aims and
desires of a number of people who have been developing new varieties
of Lisp, and on current research directions.

>>                                         If someone says "C is better
>>than Lisp for writing portable interpreters", then I don't say "oh,
>>no, there might be some potential Lisp that's better than C".  But
>>if someone says "Lisp is inherently worse than C for writing portable
>>interpreters", then I might well say something like this: "it's
>>turned out that way, in part for historical reasons, but it might
>>have turned out differently" or "existing implementations (or, in
>>some cases, Lisp-family languages) impose too much `environment' 
>>that may not be desired, but there are other ways of implementing
>>Lisp that would not have that problem".
>
>I believe this equally to be a meaningless quibble,

That *what* is?  That there are other ways of implementing Lisp?

>   But for the record
>I agree that how the term "lisp" has come to be understood the way it
>has is a matter of historical accident.

What a concession.  Gee, I guess you're a reasonable sort after all.

>[...]
>
>>But how can you tell to what extent a problem is intrinsic to Lisp
>>rather than to the peculiarities of certain varieties of Lisp or 
>>of particular implemenations.  An implementation that tried to
>>do as well as possible for real-time processing might be very
>>different from one that had different goals.
>
>And would, undoubtedly, result in a dialect which lisp "purists" on
>comp.lang.lisp would decry as being some sort of bastard hybrid which
>excluded all of the features that make lisp so great (have you paid
>attention to any of the dylan lists, by any chance?)

Bull.  You think that because you don't believe Lisp can be
better in relevant ways.  You are wrong.  It easily can be,
and some Lisps alreaady are.

Have *you* paid attention to comp.lang.dylan?  If you had, you'd
have noticed my articles there and not tried this ploy.  Or is
this just phase one, so you can exploit what I've said there
(which, if so, you are bound to get wrong).

>>Or suppose someone trys to design a Lisp that's suitable for
>>an application area where Lisp has not been a good choice.  Is
>>this doomed to failure?  Or could it be, instead, that Lisp
>>is a sufficiently inclusive category that a different kind of
>>Lisp might do the trick?
>
>Again, I suspect that such an attempt is doomed to failure only if it
>tried to solve all of the real-time and similar problems of current
>lisps while retaining all of their semantics and features. 

An absurd requirement.  No Lisp has all the features of current Lisps.

Now, if you were to say Common Lisp, or some other particular
Lisps, couldn't do it and retain all their features, you might
well be right.  

> A variant
>of lisp which was as suitable as C for the applications for which C is
>better would, undoubtedly, be as bad as C for applications for which
>what is currently understood as "lisp" is better.

Nonsense.  There's plenty of scope for Lisp to do better relative
to C without becoming C, something you are remarkably reluctant to
acknowledge.

Now, if you were to argue that no one Lisp-family language could do
_everything_ C does just as well as C, you might have a valid point.
Other semi-tautological claims will likewise meet little argument.

-- jeff
