Scheme vs. Common Lisp, #1: Politics

[andy@sun3.ads.ARPA (Andy Cromarty)]

This is the first of two notes on CommonLisp vs. Scheme.  I have
written two notes in an attempt to separate political concerns
from design concerns, in part to keep them clear in my own mind and
in part in consideration of those of you who, like me, generally
have neither the time nor the temperment for long political debates
on the ARPANET.  This note concerns the politics, or what I
think of (perhaps a little unkindly) as the "form rather than
the content" of the CL-Scheme issue.  Those of you who stick it out
and read through this note (and the ones that are sure to follow)
should bear in mind that, as we've already seen, politics is
necessarily a somewhat more personal discipline than is the
technology most of us are really interested in, and for that reason
writing styles for the political notes can be expected to differ
from those composed with primarily technical purposes in mind.
					asc
------------------------------------------------------------------------
Shortly after receiving Dick's flame, the following scenario popped
into my head.  You are listening in on a phone conversation somewhere
in Arlington, Virginia.

	Squires: Clint, I hear a rumor that Andy Cromarty is concerned
		 about CommonLisp's influence on the development of
		 Scheme.

	Kelly: Scheme?

	Squires: Yes, another kinky LISP dialect being designed by some
		 researchers.  It only has a fraction of CommonLisp's
		 features and they can't quite seem to decide what
		 it should look like.

	Kelly: Well, Steve, I guess I'll have to ask you to simply
		rescind DARPA's support for CommonLisp, then, and
		from now on we'll require all our AI projects to
		use Structured COBOL.


I suppose I should be flattered at the suggestion that a few sentences
from me would reshape the course of LISP history, especially coming as
it does from Dick Gabriel.  But somehow I give the research funding
community and the commercial tool market a little more credit for
indepedence of thought than this scenario (or Dick's note) suggests.

Perhaps more importantly, I am somewhat troubled by the idea that
Dick would advocate censorship of ideas and opinions concerning LISP
design and development (viz. his instructions that we "Don't let
anyone outside this list see Andy's message.").  My assumption is
that the RRRS-AUTHORS list exists for the purpose of supporting "open
discussion within a closed community" concerning what form Scheme
should take, and that we all implicitly agree to attempt to ground
our argumentation for our favored alternative views on a substantive
technical basis.  In this regard, I probably agree with the
suggestion that my comment "represents a low point in political
thinking."  I think the implied converse option -- that we all need
to suppress concern or public discussion about the *costs* of CL
compatibility, or for that matter, any other dangerous thoughts we
might have -- represents a new high water mark in politicization
of the Scheme design process, and I would not feel complimented to be
accused of having set that new standard.  Certainly there are others
in the Scheme community with whom I disagree, but I cannot imagine
proposing (for example) that we censor Dan Friedman because his
ideas about internal DEFINE differ from mine.  Quite the contrary: I
look forward to hearing why alternative views are held; and when I
decide I can't stand the heat, *I* get out of the kitchen.

But yes, please don't repeat my messages outside this community.  I
think we all assume that our discussions are held reasonably private
by this community, since this is still a design-in-progress, and at
the present I'm sensitized by having been poorly quoted a little too
often in the press recently.  (And anyway, if anyone at DARPA
wants to know what I think of CL, they have my phone number.)

Now let's take a good hard political look at who disagreed most
vocally with my comment.  The few responses I've received so far all
have been from competent LISP designers and implementors, to be sure.
But it is also true that they have been from: the implementor(s) of
Texas Instruments' Common Lisp and Scheme products; the author of the
premier Common Lisp text; and the president of the most successful
and best know Common Lisp product company in the world.  In addition,
many or most of these people were personally involved in the Common
Lisp design effort.  Their credentials are impeccable, but their
goals and commitments may not be the same as those of, say, a
professor who is using Scheme for its pedagogical value and has no
career or financial stake per se in the long-term viability or
political acceptance of this year's best production quality LISP
environment.  I certainly believe that having their views represented
is critical to a good Scheme's development, and I made it clear in my
original note that I do consider myself to be an outlying point in
the distribution of views on CL vs. Scheme.  But I think they are,
too; and let us not assume that the most vociferous advocates of
extreme positions (myself included) represent either the norm or the
best compromise position to take.

Since Dick couldn't see from his location down the street that my
tongue was towards the side of my mouth when I used the term "dark
forces," let me say that (a) I think Common Lisp is one of the most
successful technology results of any standardization committee I've
seen and (b) my reference was to the risk of Scheme becoming just
like Common Lisp, rather than a criticism of the quality of Common Lisp 
as a LISP.  Overall, Common Lisp is very good at being what it tries to
be.  I am utterly unconvinced that that's what Scheme is trying to
be, however.  I will treat the question of the goals of the two
languages in my companion note, but for now suffice it to say that
the idea that these languages have (forgive the pun) common goals
strikes me as nonsensical.  If that were true, we could submit Guy's
excellent book to SIGPLAN and retire this list.  I might go so far as
to say that it is precisely because Scheme exists that Common Lisp
can be successful, in the following sense: Those of us who are
concerned with what LISP should look like for the next several
decades can preoccupy ourselves with design debates over Scheme
morality, while people like Dick and Guy go on to take a snapshot of
what the community knows about good LISP design and then integrate
that knowledge, addressing and overcoming all the political obstacles
along the way, to produce a viable, saleable LISP product.  And good
luck to them; but I do not see that Lucid's chimeras need to be ours.

Rather than worry that people will learn that there is more than one
LISP, let's advertise the fact.  Let's make it clear that LISP is an
ideal language for embedding new constructs in, and that the presence
of a good heavily-featured standardized dialect has not quenched the
long-standing historical drive for LISPers to remain at the
forefront of programming language and programming environment design.
Let's advocate a plethora of LISP-like languages to get people out of
the Pascal-derivative language design syndrome and instead get them
directly and cleanly addressing individual hard language design
problems, like the keyword shadowing problem, design of appropriate
multiprocessing constructs, embedding of evidential reasoning
techniques into a programming language, integration of advanced
database technology into the programming environment in a coherent
fashion, getting distributed inheritance graphs to work across
loosely-coupled processors, and (somebody, please!) developing a
reasonable model of I/O.  Let's get them thinking that LISP is not
dead, that it is not a "solved problem," that it's there to
experiment with, and that there are and will continue to be good
reasons for all the debates we engage in on how languages should be
designed.

					asc

p.s. Dick, if you're still pissed off at me, we can go out for
     dinner at the LISP conference and you can throw darts at me.