when rational discussion was still a possibility

[Jan Erik Moström]

You can do this yourself, the link where to do this is at the bottom of
each email

On Mon, Sep 8, 2014 at 1:58 PM, Joel MaHarry <joel.maharry at ulrichmaharry.com
> wrote:

> please take me off of this interminable discussion
>
> *Digital and brand communications*
>
> ..........................................................................................................................................
> Joel MaHarry | Creative Director
> joel.maharry at ulrichmaharry.com
>  O (310) 504-1790 | D (310) 993.1334
> 1528 6th St., Suite 512
> Santa Monica, CA  90401
> www.ulrichmaharry.com
>
> .........................................................................................................................................
>
>
> On Sep 5, 2014, at 9:16 PM, John MacFarlane <jgm at berkeley.edu> wrote:
>
> +++ Michel Fortin [Sep 05 14 17:07 ]:
>
> 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,
>
> What you did at the beginning, I gather, was to port (and then extend)
> an existing implementation, Markdown.pl.  The same will be possible with
> CommonMark, which provides two implementations that use the same parsing
> algorithm, one in portable C and one in 1540 lines of javascript (with
> no library dependencies).  The javascript implementation doesn't use any
> unusual javascript features and should be straightforward to
> port to other dynamic languages: perl, python, ruby, PHP.  (Or you could
> just use the javascript library client-side and skip the server-side
> rendering.) Those who work with compiled languages will be able to use
> the C library directly.
>
> The parsers are both fast and accurate.  The original C parser I wrote
> was about as fast as discount.  An expert C coder is now working on
> otimizing it and, without changing the algorithm, has managed to make it
> about as fast as sundown, which is very fast indeed (0.01 seconds to
> parse a 1MB document, for example).  When optimization is complete, it
> should be even faster.  The javascript parser is also very fast (0.28
> seconds for the above-mentioned 1MB document, running in the Chrome
> browser).  By comparising, Markdown.pl takes 250 seconds on the same
> input, and pandoc takes 3.19 seconds.
>
> John
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20140908/b0e7e8ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UM_logo_sig2-1.jpg
Type: image/jpeg
Size: 24684 bytes
Desc: not available
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20140908/b0e7e8ec/attachment-0001.jpg>