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

questioning fairness/purpose of Scheme Implementors Workshop



   Date: Thu, 29 Feb 1996 16:16:44 -0800
   From: Ken Dickey <KenD@apple.com>

   What is important, IMHO, is that a *small* group of the right people get
   together to discuss things.  The history with Scheme Authors has shown that
   [1] eliminating non-implementors removes 99% of the chaff/noise,

When has there ever been an implementors-only by-invitation meeting?

   [2]
   working together as a small group works--for Schemers.  In contrast to the
   CommonLisp Standard, the IEEE Scheme Standard went like a rocket.

The IEEE standard had ample opportunity for community input and did not 
involve meetings of exclusion.  I don't think that's relevant here.

   It tried
   for less, and succeeded.  I don't care if this process is fair--only that
   it is effective.

Not even to the people who are the original authors??  And you want their 
support?  Or are you counting on the fact that you think you haven't excluded
a majority and so you'll win in a headcount?  I'm quite offended by this 
position.

   Taking your hint, it would be good to invite a *small* group of people like

Why should the number not be equal to the number of implementors?  A kind
of "house of lords"/"house of commons" approach?  Can you give some basis 
for saying that an implementor-dominated discussion is best?

   Michael Eisenberg who have spent years building systems in Scheme to talk
   about the usability issues.  My personal belief is that Scheme has become
   moribund because of its lack of approachability and usability (relative to
   other vehicles).  John Ramsdell also comes to mind as a creative influence.

In my experience, approachability and usability are almost always hurt most
by inviting implementors without users.  When you don't have users  you get
into fights over whether (define (foo x) x) is too advanced a syntax, and
whether you should perhaps just stick with (define foo (lambda (x) x)) because
it is administratively simpler for implementors.  If you get a few users 
in the room, my guess is they will tell you that it's nuts to waste time
talking about (define (foo x) x) being too experimental and will tell you
that the lack of willingness to make even the smallest accomodation to syntax
is one of the things that makes the language unapproachable.  (yes, i know,
macros help on this case.  it's just an exmaple that i think shows the issue
clearly.   but if there were more users involved in the process from early
on, they'd tell you that fixing define didn't have to wait for a full blown
macro proposal.)

My fear is that if you only invite two or three very sophisticated
users, they might as well be scheme implementors since they'll often
be people who succeeded in spite of what scheme has been over the
years, not people who represent those held back by it.  If
approachability is your concern, inviting a few skilled pals won't get
the kind of "garden variety" feedback that will tell you why the
define syntax debate should never have been allowed to persist for so
long, and why modern equivalents of same should likewise be reconsidered.

   FYI, my "short list" of problems with Scheme is pretty well known and has
   primarily to do with development and delivery environments:
	Cross/Multi-platform visual editors & GUI builders
	Separate compilation & source code management => Modules
	A standard object system      [perhaps as a library]
	A standard exception system   [perhaps as a library]
	Performance Measurement, Resource usage visualization & Tuning tools
	More flexable memory management
		   [immutable, static, dynamic, block, finalizers]
	Standard foreign function & data interface

each of these will radically affect how users perceive the language.
how can you hope to make any headway on making the system approachable
if you don't have even a few users there (people who don't design
systems) to judge the result?  i think the danger of inviting only one or
two people from the user camp is that individual idiosyncracies will
dominate.  among the implementors, there is a healthy degree of variation
such that there's little risk that the implementors will all stand behind
a certain point of view.  if you insist on "choosing who will represent
the users" (rather than them choosing), you will already skew the results.
if you further skew it by insisting the numbers be smaller than your own,
you virtually assure they will have an insufficient voice.

Sorry for being hard-line on this.  But as one of the underrepresented
non-implementors, I see it as my essential role.  I have always felt I
was part of an underrepresented group even when I've attended, but now
I find myself in a group that is not asked to attend and which might
only grudgingly be allowed token representation.

I am honestly very annoyed and dismayed and insulted at the degree of
elitism I'm seeing here, and saddened by the degree to which I
personally feel shut out of, after contributing substantially in time
and energy over the years.

If you want to call this a military action and say you're trying to
break off and form a new leadership for scheme, please feel free--then
people can see it for what it is.  But if you want to paint this as if
you're just continuing in the obvious way that follows from how things
have been, I think you have more to justify.  And I feel as if the
latter is how this is being portrayed.