evolving the spec (was: forking Markdown.pl?)
pagaltzis at gmx.de
Sun Mar 2 19:33:41 EST 2008
* Yuri Takhteyev <qaramazov at gmail.com> [2008-03-01 00:05]:
> 2. As Thomas suggested, we should first reach some agreement as
> to what if anything needs to change from the original Markdown
> or how the "holes" are to be filled. _Then_ try writing a
> grammar. I suggest that we do this first part in plain English
> (and perhaps some pseudo-code), using the wiki to record the
> decisions and the highlights of the dissenting views, and using
> the mailing list for the actual discussion.
That won’t work. You can try to do it this way, but you will
discover that in step 2, you will throw away everything you did
in step 1, or very nearly. Why would I say that, you ask?
I submit the following excerpt from the foreword of
[Structure and Interpretation of Classical Mechanics][SICM] for
This book is the result of teaching classical mechanics at
MIT for the past six years. The contents of our class began
with ideas from a class on nonlinear dynamics and solar
system dynamics by Wisdom and ideas about how computation can
be used to formulate methodology developed in an introductory
computer science class by Abelson and Sussman. When we
started we expected that using this approach to formulate
mechanics would be easy. We quickly learned that many things
we thought we understood we did not in fact understand. Our
requirement that our mathematical notations be explicit and
precise enough that they can be interpreted automatically, as
by a computer, is very effective in uncovering puns and flaws
in reasoning. The resulting struggle to make the mathematics
precise, yet clear and computationally effective, lasted far
longer than we anticipated. We learned a great deal about
both mechanics and computation by this process.
And isn’t this your experience when you go to write code? Every
time I sit down to write any non-trivial program, I discover that
my idea of how it would be architected was flawed; I overlooked
large areas, the APIs I envisioned wouldn’t work, or they are
horribly inconvenient, the approach I imagined cannot even work,
and so on. The sooner you start writing code, the sooner you find
Further, imagine: the book authors are talking about *classical
mechanics*. That is formulated in *mathematical notation* and
there have been *over three centuries* of work on it, yet there
are big flaws in that notation.
How much less useful must natural language be if you want to be
> Let's _try_ to do it by consesus. It might just work. If we
> can't agree and have to resort to voting, we can then figure
> out how to handle that.
The IETF uses a consensus process for all their work, so in the
Atom WG we did it that way. There were a few cases where it was
extremely difficult to achieve consensus, because there were
multiple positions with wide support, but a voting process would
only have aggravated the problem, even if it had led to a faster
decision, and would have been a drag on the majority of the work
that was largely uncontroversial.
The cornerstone to make this work is a fair moderator who is
capable of ignoring his own opinions and biases while making a
> I suggest that for everyone's sanity we divide both levels of the
> specs into a "macro" and "micro" part.
Agree with everyone else about calling this “block” and “inline.”
I’m not sure a strict separation is actually feasible. Given some
of the bugs in Markdown.pl, I think sometimes you’ll have to peek
inside the block in order to decide where and how things start
Or maybe some of these cases can be legislated out of existence
by changing Markdown slightly.
> A detailed and agreed upon spec "in English" will already be a
> big step forward.
Not very, honestly. If the group fails to produce a grammar
specification, it would help more to try and make a really big
test suite than it would to write more English.
Aristotle Pagaltzis // <http://plasmasturm.org/>
More information about the Markdown-Discuss