Pandoc Markdown and ReST Compared (2013)

i am in the process of releasing "zen markup language".

it's "lighter" than all the other light-markup languages.

it's more _powerful_ than the others, including asciidoc.

it's also far more agile, and much easier to understand.

and i won't allow it to be fragmented, like markdown is.

i've coded converters in javascript and other languages.

the javascript minimizes well for inclusion in web-pages.

i have cross-plat apps, and a web-app converter with a.p.i.

output formats include .html, .epub, .mobi, .pdf, and more.

if there's anything i haven't thought of, do please tell me.

you can reach me at my e-mail address given in my profile.

-bowerbird

For me Markdown wins just because I'm used to dealing with it daily on GitHub.

Sidenote: Wish Github Flavored Markdown would adopt some nice things from Pandoc, like multiline tables.

Most the tools we have for WYSIWYG document creation lacks determinism and portability. For the latter, one could argue that there are open formats, but still, there should be a program that can interpret the format; whereas with plain text, such a need is void, as it is possible to view the document on any decent system. For the former, the argument might be that the modern word processors provide the facilities to deterministically lay out a document through the user interfaces they sport, but then because the formats they save are either are endemic to themselves or badly supported in other software* this feature is not of much use.

I can open a Markdown/ReST/Textile/... file with any text editor, including Notepad, Vim, Emacs etc., and also view it through more or less programs, or just cat them. I can pass them through head or tail; search them with common utilities and even edit them with some others. I am not bound to any programs in order to edit my program. If, on a computer I have to use, there is no Word, or Writer or Pages, I can still edit/read the document. I can read it online, via a browser. I can use programs that are decades old, and I also will be able to read the file decades later. When I send the file to someone else, I can be sure that they will be able to read it. Any usable operating system has a text editor bundled. This level of portability is just a dream for WYSIWYG editors. For these advantaged, I happily trade editing convenience off.

* Last summer, my cousins needed to use my computer for editing a docx document that was important for their undergraduate education. I was running Ubuntu OS at the time, so I told them to use the LibreOffice's word processor. The experience was bad; the document did not render properly, editing was problematic. This is the only case I can provide as an example to support my argument, as it has been multiple years since I used a word processor program.

> ReST feels more well thought-out, generally.

It's certainly set up for extensibility, although some areas are a pain (e.g. blank lines may be ignored entirely, change vertical spacing or change semantics, that can be annoying).

The toolchain is also fairly complex and very badly documented (Sphinx itself is better documented than docutils, but either way you end up wading through piles of code to understand what happens, why, and what's available in the applicative context of your extension)

The Markdown ecosystem reminds me of shell scripts in a bad way. There are a bunch of subtly and not so subtly different dialects and environments out there, and not many people have a strong awareness of these while writing, so if something seems okay "on my computer" or in Markdown's case "on my preview" then off it goes.