when rational discussion was still a possibility

[Michel Fortin]

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