[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