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: <CvtqwL.2zK@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: <CvB1DL.6FJ@triple-i.com> <CvF292.HAM@cogsci.ed.ac.uk> <Cvny60.K8J@triple-i.com>
Date: Thu, 8 Sep 1994 18:48:20 GMT
Lines: 137

In article <Cvny60.K8J@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>In article <CvF292.HAM@cogsci.ed.ac.uk> jeff@aiai.ed.ac.uk (Jeff Dalton) writes:

[Some convergence at last, so I will try to make this relatively short.]

>>But in almost every article in which you say things I think are
>>reasonable you couple them stronger claims that I find less so.
>>However, many times when you seem to be making a strong claim it's
>>not clear exactly what it is.  Perhaps if it were clearer, I might
>>agree with you.  I don't know.  
>
>I do not know how to present my claims any more clearly.  I also am
>completely baffled in what way the seem so vague to you.

I tried to explain both why I thought them unclear and why I
might agree with more precise versions over several paragraphs
beginning with:

>>For instance, you mention "the kinds of applications for which I feel
>>that C is better suited than current lisp implementations".  But what
>>kinds of applications are those?  You wrote:

and ending with:

>>So it looks like you might be saying Lisp loses to C in every case 
>>in which run-time performance is the dominant factor, even when its
>>possible to write a Lisp program that's just as fast as the C program,
>>because you'd have to artificially avoid the very features that can
>>give Lisp an advantage over C in the first place.

You seemed to think I regarded the quote immediately after "You wrote" 
as "a description of a kind of application".  I didn't.  The several
paragraphs have to be considered together, but even collectively
they may have been unclear.  (Evidently not *clear enough*, in any
case.)  It's probably not worth going into this further.

Anyway, we can now use this version of "what kinds of applications":

   The _kinds_ of applications where the above cited consideration
   [needing to avoid features] typically causes lisp to be a worse
   choice is, as I have frequently stated, system-level, real-time,
   and applications with similar requirements for continuous
   high-bandwidth interaction with hardware or the user which can 
   only be achieved by the kind of application- and hardware-specific
   optimization which is C's forte.

I was with you up to the end.  What application-specific optimizations
does C do?  What hardware-specific optimizations does C do and Lisp not?
I'm not sure what you have in mind here.

In any case, what do you think of work on real-time GC?  Is it
pointless?  Or will Lisp lose even if the GC problems are solved?
If so, why?

>>Of course, you might argue that all you're really saying is that
>>Lisp loses when it's *difficult* to avoid higher-level features.  
>
>Exactly.  Or it can be impossible to avoid them in some cases (mainly
>the cases I assume you would attribute to poor implementation strategies.)

In many cases I would, but not all.  But to me the details matter.
The points that can be justified are often narrow points, I find.

>   Again, the arguments to
>which yours were a response were presented as reasons why I consider
>it wrong to suggest that criticisms of _current_ implementations of
>_current_ dialects on such performance grounds are unfounded, in the
>context of someone being given what I considered bad advice as to what
>criteria to use in choosing a programming language for any given
>project.

Ok.  But my position is that criticisms of current implementations 
of current languages are well-founded almost entirely because of
properties of these langauges and implementations and not because of
general considerations about Lisp or richer semantics or higher-level
features.  (In part, this is because such general reasoning has so
often been wrong.)  Moreover, the implementations are more "to blame" 
than the languages.

This may still be a "real" disagreement between us, in addition
to the one discussed below.  It's real, if a disagreement, because
of different implications for what we can and should do about it.

>I said that I thought there was little, not no, real disagreement.
>Here is, indeed, a significant point on which we differ.  I am much
>more satisfied with the current state of affairs - using a variety of
>different tools for the different tasks for which each is well-suited.
>I am less concerned with, and less optimistic about, the possibility
>of developing some "universal" language which would be well-suited to
>all or almost kinds of applications.

But you don't actually know very much about me.  You may be assuming
I fit a standard type that I do not.

I use a variety of tools and am reasonably satisfied by many of them.

I am not at all concerened with developing a universal *language*.

I am concerned with whether a particular class of tools -- the Lisp
family of languages -- will survive and in what form.  I am therefore
concerned with whether people are encouraged or discouraged from
using Lisp and encouraged or discouraged from developing new langauges
and implementations.  I am also concerned whether a number of false
impressions of Lisp are reinforced or countered.

>>I think it's wrong to suggest that we know right now which
>>applications are for Lisp and which are for C or that any attempt
>>to make Lisp better in one way will make it worse in another.
>
>Again, we are just talking about different things.  I disagree with
>very little in the specific points you raise below.  But the fact is
>that all of these things are issues for research and future
>development.  [...]

True.

>I know from experience.

Experience is specific and often misleading when generalized.

>But it is as unreasonable to expect a complete analysis of the
>run-time behavior of a variety of large, complex applications in this
>context.  Nor do I feel that such analysis is really required,[...]

Kirk -- I still don't know whether you're talking about a
factor of 10.0 or 0.10.

>I do not dispute the importance and the likely positive practical
>benefits of continuing to do research and development in language
>design and implementation.  However, I cannot afford to take the
>"mature" attitude that "it's too soon to tell" when I am required to
>choose or recommend a programming language for project that must be
>developed _today_.

I happen to be concerned about the future as well as today.

-- jd
