on the philosophical aspects of a specification
Bowerbird at aol.com
Bowerbird at aol.com
Mon Mar 3 17:44:02 EST 2008
well, i had said i wouldn't reply on this, but i think that
this post will still manage to be productive. i hope so...
> If every implementor teases a different intent
> out the same document, the user loses.
well, yes. but that's pretty obvious, isn't it?
there needs to be agreement among implementers.
i would think that goes without saying.
however, implementers can reach agreement easily,
by leaving users out in the cold, brushing them off
with a "you will need to follow the spec" which seems
-- if i understand markdown's cornerstone correctly --
to be outside gruber's comfort range for his creation...
nobody benefits from _true_ ambiguity. kill that off...
but if you cannot be clever enough to allow "corner" cases
to be resolved _however_different_users_intended_them_
-- especially if those different intentions could be _easily_
understood by a naive person viewing them in plain text --
you need to go back to the drafting table and do more work.
in other words, the same input must create the same output.
but if people express different output using _similar_ input,
then you need to work to find a way to differentiate the input,
and not simply think that you can tell one of them to change...
so before considering two things as "the same", work _hard_
to see if there's some way -- any way -- to differentiate 'em...
i mean, that's _my_ opinion, but my opinion counts much less
than those of the implementers, and far less than gruber's...
the thing is, i like the _idea_ of markdown, which should not
be surprising, since i'd been working on my own non-markup
form of markup (for project gutenberg's e-texts in particular)
before markdown was invented. since i couldn't "write a spec"
-- as my target documents are already widely propagated --
i had to _get_clever_ to tease out the different interpretations.
not only did it lead to code that's stronger _and_ more flexible,
but i found the challenge to be stimulating _and_ productive...
> Why then does the fallacious argument that
> a spec would represent a loss for the user continue?
aren't you loading the dice by labeling it as "fallacious"?
i'm not necessarily arguing that _any_ spec would do that.
but some might... most especially by some implementers...
and according to markdown, users can't be wrong, can they?
so far, i've agreed with every aspect of michel's take on this...
It's Tax Time! Get tips, forms, and advice on AOL Money &
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Markdown-Discuss