[ruby-talk:17536] Re: Ruby on Slashdot

Hello --

[Sorry, this got kind of long.]

On Mon, 9 Jul 2001, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "[ruby-talk:17519] Re: Ruby on Slashdot"
>     on 01/07/09, "James (ruby-talk)" <[e-mail]> writes:
>
> |What are the thoughts on Ruby (eventually) being submitted to a standards body.
> |such as ECMA?

It's a little disconcerting that ECMA's own Web site says:

    This website is best viewed with a 1024/768 screen resolution

So much for standards.

Anyway....

> [...]
> So if someone is really willing, how about submitting somthing very
> similar to Ruby but has different name, (kinda like JavaScript and
> ECMAscript)?  The future Ruby can learn a lot from the committee
> effort from this standardized language.

Probably so -- but I wonder whether it would learn more than from the
kinds of detailed discussions and contributions we already have.
Would there be any level of language critique or scrutiny that such an
arrangement would open up, that isn't already open?

> This satisfies everyone, including people who needs standardized
> language, people who like discussion in the committee, and me who
> hates the committee discussion. ;-)

If people want a standardized language because they have an abstract
love of standardization, perhaps they should write their own language
:-)

Seriously: the danger, I fear, would be that giving everyone what they
want, in the short term, would disrupt the unity of the language and
the coherence of its process of growth.  I believe that what we've
been doing here, by way of discussion of language features, RCR, the
benevolent dictatorship, etc., is really good -- not just as a
stepping-stone to some other approach to language description and
evolution, but *really good*.

And on the assumption that I'm right :-)  here are some slightly more
practical suggestions.

Let's say we kept the basic life-cycle of Ruby essentially the way it
now is.  Then, it would then be possible to extract *descriptive*
standards from the major releases.  This could be accompanied by a
cycle of tests for conformity, and whatever else would be necessary
for writing implementations.

"Extracting" a standard, strictly speaking, would include
standardizing bugs... so there could of course be some iterative play
between core Ruby and the descriptive standard.  But the idea would be
to protect the current language-development culture while still
presenting a formal standard as an interface to the world.  (As
opposed to developing a standard separately, and then making core
language growth answerable to that standard, or having just a kind of
advisory relationship between Ruby and the standard.)

The descriptive standard approach would mean that:

  * the current process, which in my opinion is successful from the
point of view of language development, could continue;

  * major releases of Ruby would always conform to a standard, because
the standard would be based on them -- which isn't as circular or
self-serving as it sounds, because those releases are *already*
subject to tremendous scrutiny;

  * the floodgate of implementations could open;

  * core Ruby development would benefit from its own (descriptive)
standards, because the process of reverse-engineering a standard could
expose weaknesses.


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav