[E-Lang] a slightly calmer Zooko attempts to clarify his meaning about prescriptivism (was: Re: Ppooko says "Dammit, stop being overly prescriptive.")
Tue, 03 Apr 2001 14:37:53 -0700
Okay I was pretty emotional when I wrote "Dammit, stop being overly
prescriptive.", and I think I overshot the mark a bit.
For example, I said:
> I think we should start from the assumption that E v1.0 is going to ship with
> array-indexing syntax, with mutable collections, and with anything else that
> programmers think that they need, and it is going to ship soon, and the
> discussion about security issues is aimed at minimizing the danger of these
> required features or at making sure we don't preclude future improvements, not
> at designing a language in which it is as hard as possible to write insecure
But I am not really certain that mutable collections are absolutely necessary
-- my opinion about that hasn't yet gelled.
What I intended to emphasize was the point I alluded to in the first paragraph:
> It seems that the E gurus (not just Tyler) are infected by a desire to
> prescribe the behaviour of their programmers as much as possible, rather than
> to do so as little as possible.
In the discussion about an indexing method and operator people seemed to be
saying "Can anyone think of a good argument that programmers need this
feature?". This is very much the wrong question to ask! Because programmers
from the Big Five languages *expect* and *want* that feature, the question
needs to be "Can anyone think of a compelling argument that including this
feature will cause *so* much damage that it is better to increase the risk of E
becoming a little-used, "could have been" language than to include this
As far as I can tell, there is no argument that comes near to that conclusion
with regard to indexing operators.
Now the same standard needs to be applied to mutable collections and to using
`.' for method invocation syntax.
There *is* an argument at hand that *might* lead to that conclusion with regard
to mutable collections -- the security argument. I will try to address this
issue in a separate letter.
The argument about `.' as method-invocation syntax does not seem to lead toward
that conclusion, to me. I will try to address this issue in another separate
Remember: as far as features that programmers are familiar with, the correct
approach is not "We will omit this feature unless we can think of a reason that
programmers *should* use it.", but "We will include this feature unless there
is a compelling reason that we can't do that."
By the way, I also made one mistake in my "dammit" article which changed the
> (By the way, high-powered iteration with closures is apparently one of the
> very shiniest arrows in Ruby's quiver, judging from the many pages devoted to
> it in the Ruby book. Nonetheless, nobody in Ruby land is blinkered enough to
> think that they can get anywhere by offering a language without an array
> indexing iterator.)
^^^ I meant "operator". Sorry for the confusion.