[tap-l] Descriptive vs Proscriptive
David E. Wheeler
david at kineticode.com
Fri Apr 11 18:15:48 UTC 2008
On Apr 11, 2008, at 03:59, Michael G Schwern wrote:
> Quite rapidly everyone shifted over to thinking that we should only
> allow
> "X-foo" for user keys because it's unambiguous. Then we don't have
> to worry
> about characters that don't have an up/down-case concept. And we
> can eyeball
> a user vs reserved key slip. And it looks like mail headers and
> we're all
> used to reading mail headers. And we can always allow a wider use
> later.
> Etc...
What about reserving only lower-case ASCII for internal use, and
anything else is fair game? That's unambiguous and pretty easy to
enforce, plus is close to your original proposal, since 9x% of the
time, people will just use uppercase ASCII anyway.
> Seems like a fine solution. Everyone agreed but me. It seemed like
> I was
> just being a sore loser, and maybe I am, but I don't often dig in my
> heels
> unless I think it's really, really important to get it right. The
> last time
> that happened was the business about Test::Harness 3 merging STDOUT
> and STDERR
> which took months to resolve.
It seems unnecessarily limiting to me.
> I don't really care so much about doing "Foo" or "X-Foo". It's all an
> aesthetic choice. What worries me is that we're encoding an
> aesthetic choice
> at all. That we're proscribing behaviors because we think it might
> be ugly or
> hard to read or harmful or stupid or redundant or difficult to
> specify. We
> have too narrow a vision to make that decision. All we can
> truthfully say
> about the future is that our predictions will be wrong. If we
> proscribe what
> we think might be bad, because we're going to be wrong, we also
> proscribe what
> might be good. If we proscribe what is bad now, because things
> change we also
> proscribe what might be good later.
I agree. I think that the spec should actually limit a very small
subset of a universe of options rather than limit the consumers of
that spec to a small subset. Make the spec have to think harder about
what's allowed.
> This is why we should be descriptive instead of proscriptive.
> Descriptive
> means to specify only what you need and leave the rest open. It
> provides a
> playground for users to fool around in and try things out that we'd
> never have
> thought of. It provides the cracks into which really clever people
> can wedge
> radical new ideas to advance in wild new directions. It's the
> flexibility
> that allows a language to survive for 20 years and all the
> unpredictable
> changes that come. Perl survives and grows that way, TAP should too.
Amen to that.
Nice post, Schwern.
Best,
David
More information about the tap-l
mailing list