Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!newsfeed.pitt.edu!dsinc!spool.mu.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!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: <Cw4rEu.2sB@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: <Cvo0E7.Gws@cogsci.ed.ac.uk> <CvvGsB.2AG@triple-i.com> <LGM.94Sep11120213@polaris.ih.att.com>
Date: Wed, 14 Sep 1994 17:32:53 GMT
Lines: 57

In article <LGM.94Sep11120213@polaris.ih.att.com> lgm@polaris.ih.att.com (Lawrence G. Mayka) writes:
>In article <CvvGsB.2AG@triple-i.com> kirk@triple-i.com (Kirk Rader) writes:
>
>   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.
>
>Common Lisp implementations often contain extensions that "add back
>in" most-all the features for which C is praised: operations that
>compile to a single machine instruction, for example.  Theoretically,
>one could go to the trouble of standardizing such extensions, and
>defining their relationship to the rest of Common Lisp, the result
>being essentially a new language that is a union of Common Lisp and C
>functionality, but with regular syntax.

What puzzles me in Kirk's view is why someone would think that the
process of Lisp becoming "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"
must have *stopped*.

It's happened for a number of applications so far, but for some
reason cannot go further.  I find such views bizarre.

(Indeed, it can easily go further for some applications just by
producing smaller images.  But I suppose Kirk really means real-time
and like applications and not in fact "the kinds of applications to
which C is currently better suited" in general.)

Anyway, in additions to the techniques LGM mentions, we might note
that (1) GC technology is still improving, (2) type inference has not
been exploited as much as it could be, (3) otehr forms of compile-time
analysis is still becoming more sophisticated -- e.g. compilers that
look at the whole program, (4) more use could be made of the kinds of
type information already available (see e.g. the thread on "data
bloat", (5) techniques for limiting the scope of redefinition
(freezing or whatever it is in Dylan, confining redefinable classes 
to a separate metaclass as in some EuLisp- related stuff), (6) 
different ways to package implementations (eg as libraries or
shared libraries).

No doubt a determined skeptic can find ways to seemingly dismiss all
of this (e.g. by characterizing things that can be compiled away as
"trivial" and "syntactic sugar", or by claiming that the resulting
languages won't be "well-suited to the kinds of applications for which
lisp is currently better suited"; and again by talking of "Lisp"
as if it were a single language).  N.B. e.g. not i.e.

-- jeff


