<story><title>Beyond Markdown (2018)</title><url>https://johnmacfarlane.net/beyond-markdown.html</url></story><parent_chain><item><author>sqs</author><text>I understand where the author is coming from and respect their contributions to Commonmark.&lt;p&gt;But...&lt;p&gt;There are tons of markup languages for prose that have well-defined specs.&lt;p&gt;So, why did Markdown win?&lt;p&gt;IMO, &lt;i&gt;because&lt;/i&gt; it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text.&lt;p&gt;Whereas a perfectly-spec&amp;#x27;d markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision.&lt;p&gt;You see this theme in so many places in tech: &amp;quot;less is more&amp;quot;, the Unix philosophy of everything-is-a-file, messy HTML5 over &amp;quot;XHTML&amp;quot;, ML extraction vs. explicit semantic web, etc.</text></item></parent_chain><comment><author>drawkbox</author><text>&amp;gt; IMO, because it does not have a well-defined spec.&lt;p&gt;Same reason that JSON won.&lt;p&gt;JSON and Markdown are base standards that were generated by market need to simplify.&lt;p&gt;JSON won because it was not overly complex and there was some flexibility. If you need more go YAML or use JSON as a platform for more.&lt;p&gt;Every attempt to change JSON has and should be shot down.  JSON really just has basic CS types: string, int&amp;#x2F;number, bool, object, lists. From there any data or types can be serialized or filled. With JSON you can do types via overloads&amp;#x2F;additional keys, you can add files by url&amp;#x2F;uri or base64, and any additional needs using parts of basic JSON. Even large numbers can just be strings with type defs as additional keys&amp;#x2F;patterns. Financial data can just use strings or ints with no decimal largely because this is the safest way to store financial data to prevent float issues.&lt;p&gt;KISS is life and sometimes things are just done, no improvements needed. Now you can take JSON and add things on top of it if you want. Same with Markdown. The base doesn&amp;#x27;t need to change... ever.&lt;p&gt;Don&amp;#x27;t SOAP my JSON. Don&amp;#x27;t HTML my Markdown. Though you can add specs (JSONSchema&amp;#x2F;OpenAPI) and formatting tools on top in a processing step. For messaging and base content, they are perfect, simple, clear, concise and no need to change.</text></comment>
<story><title>Beyond Markdown (2018)</title><url>https://johnmacfarlane.net/beyond-markdown.html</url></story><parent_chain><item><author>sqs</author><text>I understand where the author is coming from and respect their contributions to Commonmark.&lt;p&gt;But...&lt;p&gt;There are tons of markup languages for prose that have well-defined specs.&lt;p&gt;So, why did Markdown win?&lt;p&gt;IMO, &lt;i&gt;because&lt;/i&gt; it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text.&lt;p&gt;Whereas a perfectly-spec&amp;#x27;d markup language would probably evolve toward an unreadable-to-humans mess in the committee-driven pursuit of precision.&lt;p&gt;You see this theme in so many places in tech: &amp;quot;less is more&amp;quot;, the Unix philosophy of everything-is-a-file, messy HTML5 over &amp;quot;XHTML&amp;quot;, ML extraction vs. explicit semantic web, etc.</text></item></parent_chain><comment><author>axblount</author><text>Also, &amp;quot;worse is better&amp;quot;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Worse_is_better&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Worse_is_better&lt;/a&gt;</text></comment>