Re: when rational discussion was still a possibility

[Andrei Fangli]

Times without hardware specs mean nothing, please also provide some hardware specs to get a more accurate idea about performance.




The JavaScript version is only good for preview at client-side to avoid posting to the server one to many times. To do client-side parsing and sending it to the server in the final format is a serious security leak (trusting that a post request sends a valid and harmless html is wishful thinking).




If you want to parse the Markdown text every time at the client side using JavaScript will make parsing time dependent on the users device. Think about someone using a smartphone to browse the Internet and gets to a large Markdown text and the phone is required to parse that.






Dependencies with other JavaScript libraries has some part to do with porting implementation to other languages. It also depends on how that code is written (I haven’t peaked at it yet, just saying that how code is written is another factor in porting effort).




The C implementation sounds promising, but to be able to use it (speaking from a .NET point of view) I would need to compile it to a dll and reference it through a wrapper CLI class that handles interop such as string conversion to C char array, or C wide char array and then back again with the result lest your code works only with files which can complicate things.




Andrei Fangli





From: John MacFarlane
Sent: ‎Saturday‎, ‎6‎ ‎September‎ ‎2014 ‎07‎:‎16
To: markdown-discuss at six.pairlist.net





+++ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20140906/e4ae240c/attachment.html>