Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!aiai!aiai.ed.ac.uk!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.scheme
Subject: Re: To Lisp, or not to Lisp; that is the question.
Message-ID: <4299@skye.ed.ac.uk>
Date: 11 Mar 91 18:23:32 GMT
References: <9103080432.AA06368@kolyma> <455@data.UUCP>
Sender: news@aiai.ed.ac.uk
Reply-To: jeff@aiai.uucp (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 59

In article <455@data.UUCP> kend@data.UUCP (Ken Dickey) writes:
>A small, but important clarification: let's seperate "language" and
>"programming environment" issues. [...]

>Don't get me wrong, I think that Jon's points are well taken ("Lisp"
>is not just a family of languages but a way of `doing business').  I
>am just a nit-picker who would prefer to see the discussions on this
>thread about EVAL, LOAD, INCLUDE, etc. to be posted under the heading
>of "standard interfaces to programming environment services", rather
>than "language features".

It is a useful distinction, but I think it's a good idea to remember
that some of the reasons for making it are political.  (Not all of
them, of course.)

In the Lisp community, the distinction is often used in the defense
of Lisp, to make it seem more like other languages, more static and
declarative, less dynamic, less a matter of side-effects.  For example,
in response to a claim that the Lisp programmer's ability to redefine
functions at run-time was a Bad Thing, an answer might be to say that
it was part of the environment not the language (just like it might
be part of some C environment).  That's not the answer given for
Scheme, but it's the kind of answer that's sometimes made.

But the language / environment distinction is also used _against_
Lisp.  For example, I've heard people claim that no one really likes
Lisp as a language.  It's the the _environment_ they like.  [I think
this claim is false, by the way.]  As the environments for other
languages get better, a slight variation on this argument will, I
suspect, be used again and again.  There's no reason to use Lisp for
this project, we'll be told, because we can get the same advantages
using <insert the name of your favorite C or C++ interpreter /
environment> without any of the disadvantages.

This is not to say we shouldn't distinguish the language from the
environment.  If anything, we need to pay more attention to it.  We
(that is, those of us who want to use Lisp and want Lisp to succeed)
need to make Lisp environments better.  We also need to identify and
emphasise those advantages of the language that are not just
environmental.

However, we should not let this mislead us into relegating too
much to the environment.  Different implementations of the language
can provide very different environments.  So if something is classed
as environment, it might not be present in all implementations and,
consequently, it can't be used in portable code.  If we start to
require various environmental features, the whole language / env
distinction makes much less sense except as an aid to conceptual
simplification.

I do not agree that EVAL is environment.  EVAL might be provided as
part of the environment in Scheme -- because it's not part of the
language.  But that does not mean it is inherently environmental.
In most Lisps, it is part of the language.  In this it is different
from LOAD.  EVAL is not just another way to get programs into
execution.  It is not just an alternative to LOADing them, or
typing "lisp <filename>" to the shell.

-- jd