[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Some Remarks on Standardization (by someone who has been there)



Ladies and Gentlemen:

I have heard from my friend Will Clinger and read in a message from
Chris Haynes that the Scheme group is considering pursuing an IEEE
standard for Scheme. I made some remarks to Will about this by phone,
but I would like to address them to the group as a whole. Let me say at the
outset that I do not have any deep feelings about the matter, though I
cannot guarantee that I won't present strong arguments on one side or the
other in this message. The rest of this message largely follows the
outline of Chris Haynes's (Strunk and White) message:

1) Is a Standard Necessary?

Chris Haynes points out that some businesses and educators would adopt
Scheme if it were a standard language. The Europeans believe this is true
for Lisp in Europe. I do not believe it is true in the US. The problem
with adoption of Scheme and Lisp in the US by industry is that they are
too closely associated with AI, that it is difficult or impossible to have
Scheme/Lisp-written code be linkable into an executable image along with
other code, and that the speed of code is unacceptable.  I think each of
these can be attacked, I think that solving the second reduces the
importance of the third, and that none of this has to do with
standarization.

Like it or not, Scheme is a dialect of Lisp. And right now Common Lisp is
regarded as the only Lisp worth considering. Now as you may know, I am not
a huge supporter of Common Lisp as a language - note my Critique paper with
Rod Brooks and my attempt with Will Clinger to push for a cleaner language
(in fact Scheme) at the ISO level (which attempt has not yet failed); note also
my recent interview with Unix Review. On the other hand, I am a supporter
of Common Lisp as a tool for legitimizing Lisp and for getting a decent standard
for Lisp. The strategy I use is that standarization is a two step process: first
you convince people there ought to be a standard; second, you convince them that
if there is to be a standard, it ought to be a good one. Common Lisp as a
defacto standard achieves the first of these. I was trying, with Will's help,
to achieve the second.

Splitting up Common Lisp from Scheme has some desirable and some undesirable
effects. A desirable effect is that this sends the message that Scheme is so
unlike Common Lisp that if you had doubts about Common Lisp because of
weird features, Scheme don't have 'em. An undesirable effect is that the
people you hope to convince of Scheme - industry - don't see Common Lisp
and Scheme as very different at all: maybe one is smaller than the other.

In the old days, one excuse I heard about why people didn't use Lisp was that
the ``Lisp community cannot get it together,'' by which was meant that
the various quarters could not agree on a single Lisp. An ANSI Common Lisp and
an IEEE Scheme reinforces that. I would not want to rule out the possibility
of an ANSI Scheme as a standard within the Lisp family, including Common Lisp.

I don't believe that an IEEE standard will increase the visibility of
Scheme significantly. Remember, there are ANSI and IEEE standards for all
sorts of bizarre languages (and I don't mean ADA). These remain as
anonymous to everyone I know as they were before they were standardized.

Finally, standarization is the reward for a successful language, not a
tool for making it so. Some argue that standardizing Lisp will save the
language from sinking back into academia, but I doubt this. I believe
Lisp has to fit into the rest of the world better. C is being standardized
because everyone uses it, and so with Common Lisp.

2) Will Standardization Help Motivation and Discipline?

This is somewhat of a fairy tale. What has happened with Common Lisp is
that many people who used to do the work have ducked new work because they
believe that the next guy should feel motivated to do the work. When push
comes to shove, the work gets done in informal groups who are
self-motivated, which is the current situation with Scheme - nothing will
change other than for the worse.

3) Will a Standard Improve Portability?

You can choose to have a non-validatable language (ISO prohibits this,
I think). You can also choose to leave some things up to implementations.
The standard doesn't necessarily improve things.

***********************************************************************

The arguments against standardization and the remarks Chris makes about
them are more interesting than the arguments for standardization.

4) Will a Standard Increase the Likelihood of Difficult Implementation?

Do you expect difficult-to-implement features will be added? What are some
possibilities? Or do you expect that increased pressure to conform will
require implementors to implement already-standard but difficult-to-implement
features? If these features are elegant and the right thing, why give
implementability and efficiency the upper hand (or any hand)? And if
implementability and efficiency begin to reign, what else will they
bring into the language?

5) Will Unnecessary and Flawed Features Creep In?

If Scheme currently includes only necessary features, then
necessity is based on judgement. If unnecessary but convenient
features will be left out, then there is some reason to desire an
official library. Such a library requires funding to achieve and
maintain - Common Lisp failed completely to do this although it
was an explicit goal.

The issue of technically flawed features raises the largest issue in
my mind. Throughout the Common Lisp and CLOS efforts we employed Moon's
Maxim: Do Not Standardize on Research. Standardization is codifying and
specifying existing, proven practice with minor cleanup. If you follow
this, you will not include any technically flawed features, only technically
retarded ones.

Here is a case in point: If you standardize Scheme in the next year or
two, that standard cannot include any macro facility. This is because
a PhD thesis on the topic has just been published, and no implementation
of the latest, most final ideas has been in use for long enough. The Common
Lisp macro facility is mightily flawed, but it codifies 20 years of
practice, and its flaws are well-known. This situation is very much more
desirable than casting as a standard something you just thought of. 

6) Will Research Stop?

Well, I don't know. The personal motivation for research does not stop,
but the funding for that research might stop. This has happened to the
Common Lisp community. Until this year, there was funding aplenty for
Lisp research from DARPA; now it's all gone. We standardized ourselves
out of our jobs.

Note that successful standards are revised every 5 - 10 years.

7) Will the Wrong Folks Move In?

I have to admit that the commentary on this topic reminded me of the most
despicable days of the Common Lisp effort, and it actually makes me a bit
sad. The desire to define a standard and the need to be a small group in
control are inconsistent. If you feel strongly about achieving both, you
will accomplish a situation you will regret for a long time.  When you
choose to make a standard for a language, you are saying that you have
something that the community at large uses and wants to continue to use;
this is an act of generosity and public spirit. When you turn around and
state that these very people towards whom you have shown this concern
should be excluded, you are saying that these people are incapable or
evil; this is an act of arrogance and insensitivity. Silly as it might
sound, this will come back to haunt you just as it came back to haunt the
Common Lisp folks.

There really was a Quinquevirate, a gang of five, who controlled Common
Lisp for the last year of its definition and who tried to control the first
year of standards discussion just prior to X3J13 forming. We actively tried
to exclude people from our inner circle. The rational basis was that we
were the founding fathers and knew the motivations for the decisions. But like
the Constitution, the interpretation of what we did fell from our hands and
should have fallen from our hands. The only fact that eases my own conscience
is that some people of impeccable character participated along with me.
Nevertheless, I'm ashamed of that period.

If you want to exclude the wrong people, remain informal and self-selected.
If you want to standardize, welcome outsiders - this is what you want, right?
You want converts, so don't insult them.  If you want your ideas to
prevail, then they must prevail because they are good ideas and because
you have exerted technical leadership. All standards organizations impose
a form of democracy on the process. Imagine that your worst enemies are
Chairman and Vice Chairman. Do you fear that your ideas and your ability to
lead the community at large (who will vote) are not strong enough to
prevail? If you do, then do not start the process.

Also note, your rules for voting rights exclude Steele and me.
I doubt IEEE would allow it. Some of the Quinquevirate were threatened
with lawsuits. Don't do it.

7) What's the Right Thing?

Here's a sad story. It's the story that is forcing Will Clinger out
of the ISO process. You all know that the EuLisp community was pushing
for a more Scheme-like language as an ISO standard. One reason they
felt this was is that the Common Lisp community excluded them early on.
However, the forces at large have caused Common Lisp to prevail to
such an extent that the EuLisp community seems to be backing down
and is ready to work with Common Lisp. I had hoped, along with Will,
that we could have worked with them to bring a better standard to the
international community. I think that the only way to do this, now, is
for the Scheme and Common Lisp communities to work together more closely
somehow. As you think about this statement, keep in mind that many
members of the Common Lisp world wished something more like Scheme had
been adopted.

Well, enough of this. The war for Lisp is not on the standards
battelfield anymore, anyway.

			-rpg-