Markdown Discuss - Sep 2014 - when rational discussion was still a possibility

michel said:
>   If you want to start a discussion about that new
>   Markdown-related thing making rounds on the internet
i don't want to start such a discussion.

but i find it very perplexing that so many of the people here --
who i assume are here because they _care_ about markdown
-- would allow themselves to be diverted by a topic as trivial
as _tables_ when the internet at large is more-or-less talking
about the evolution of the future of this format/tool/whatever.

>   how about asking for opinions about it?
anybody who wanted to express an opinion about the "new"
thing could have done it here last month, when john posted it
to this listserve, and rational discussion was still a possibility.

which is certainly not true in the zoo which has since ensued.

>   instead of writing poetic elephant analogies
i am a poet, so if you meant that as a dig, well, it didn't work.

>   and subtle meta-complains
what exactly was "subtle" about my complaint?  nothing at all.

i mean, it's certainly possible that the initial poster was unaware
of the large kerfluffel surrounding markdown out on the internet,
because a healthy disregard for the social media is... healthy...
but certainly _some_ of you had to have some knowledge of it.

and yet everybody is just going about your "business as usual".

>    No one bothered announcing the news here
yes, that was one of my points.

>   so no one is discussing it here.
yes, that was another one of my points.

>   If you think it's worth a discussion, start one.
i think there are a whole raft of questions that are
being obscured by this battle of personalities which
are worthy of discussion and -- indeed -- _should_
be discussed in a healthy dialog involving all sides.

but i also have _more_ than enough experience to
know that such a discussion will never happen here.

i am also aware that even if it _could_ happen here,
it'll never be the case that _i_ would be permitted to
"start" it. that's not something an outsider is allowed.

(but hey, if you want to play, chew on this for a bit:
could we eliminate ambiguities and inconsistencies,
while still retaining the flexibility that gruber desires?
and if so, how exactly would we go about doing that?
here's a good hint: do not let atwood lead the effort.)

>   But please don't start it by complaining
>   how unacceptable it is that it isn't already
>   being discussed, it's quite uninviting.
i didn't say it was "unacceptable".

i accepted, a long time ago, that _nothing_ of substance
will ever happen on this listserve.  and i'm fine with that.

but when _nothing_ happens in such a noticeable way,
i'm gonna notice it, and i'm also gonna comment on it.
because that's what an outsider does.

-bowerbird

Le 5-sept.-2014 ? 15:07, bowerbird via Markdown-Discuss <markdown-discuss at
six.pairlist.net> a ?crit :
> i am also aware that even if it _could_ happen here,
> it'll never be the case that _i_ would be permitted to
> "start" it. that's not something an outsider is allowed.
I'm not sure where you get that impression, but if you're allowed to
write poetry here then you're certainly allowed to start a discussion about
something Markdown related.

> (but hey, if you want to play, chew on this for a bit:
> could we eliminate ambiguities and inconsistencies,
After years of thinking about it, I don't think this is actually possible.

> while still retaining the flexibility that gruber desires?
> and if so, how exactly would we go about doing that?
> here's a good hint: do not let atwood lead the effort.)
Irrelevant since the first part is impossible.


A lot of people want to have a Markdown parser in their own programming
language, tailored to their own needs, and they really often want to be able to
extend it to cover their own use case.

Because of differences between the tools available in each language and
programming environments, different implementations use different regular
expression engines, or formal grammars, or they all the parsing logic in code.
This variety of tools make the tradeoffs different for every implementers.

Often, something that's easy to implement one way with a set of tool will be
hard to implement similarly with another set of tool, and vice versa. Getting
all the edge cases to parse the same way across dissimilar implementations is a
noble goal, but it has to be weighted with other goals such as having good
parsing performance, ease of maintainability, and ease of adding extra features
tailored to some specific needs. A parser that sacrifice those three last things
to conform to some standard will only fill the niche of those seeking everything
to be parsed the same everywhere.

From an implementer point of view, unless a detailed standard is written as a
description of what your own parser does, you'll have to spend a lot of time
tweaking things to match that standard. By "a lot of time" I mean more
than what it took you to implement the parser in the first place. Remember,
it's always getting the last 20% that takes 80% of the time. So you'll
spend a lot of time to achieve some dubious tradeoff. Implementers have better
things to do with their time.

So my conclusion is that if you want one or another Markdown flavor to become
the standard, you need to find a way for its implementation to be included
everywhere. But with all the diverse language ecosystem we have, and with the
varied needs of different communities using Markdown, that seems quite difficult
to achieve. I'd call that impossible.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca