<br><br><div class="gmail_quote">On Mon, May 9, 2011 at 3:30 AM, Dr. Drang <span dir="ltr">&lt;<a href="mailto:drdrang@gmail.com">drdrang@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, May 8, 2011 at 7:28 PM, bucephalus org &lt;<a href="http://bucephalus.org" target="_blank">bucephalus.org</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt; wrote:<br>
&gt; I think, even Markdowns own plurality, e.g. that<br>
&gt;   _this_<br>
&gt; and<br>
&gt;   *this*<br>
&gt; are identical, is not helping anybody, but only increasing the learning and<br>
&gt; reading problems.<br>
<br>
</div>Is anyone really confused by this? Or by the two ways of doing<br>
headers? I doubt it.<br>
<br>
I&#39;ll bet most people on this list will agree that Markdown&#39;s<br>
flexibility is a prime reason for its success. It accommodates what<br>
people are already doing.<br>
<br></blockquote><div> </div><div>Sorry, but I disagree.</div><div>The success of Markdown is just not its flexibility, but its simplicity and convenience.</div><div><br></div><div>There may be one good reason for the double syntax in some of its features (like &lt;strong&gt; and &lt;h1&gt;), and that is history. If there are communities that use different standards, then it can be a good choice to import that in a formal language, because it integrates standard conventions and that is convenient for (new) users. I am not sure how this worked in case of the Markdown syntax.</div>
<div><br></div><div>But in a clean design of a new formal syntax, flexibility is a bad choice. This is what I think I learned by making this mistake myself on several occasions. </div><div><br></div><div>You say, &quot;Is anyone really confused by this? Or by the two ways of doing headers? I doubt it.&quot; Well, I was confused. Of course, the double rule for say *this* and _this_ is simple and is not that hard to understand. But I had neither a history or habit with either *this* or _that_. So, I spend some time on the question, what the best choice would be and which one I should make my own default. You may say, &quot;whatever you prefer&quot;. But this is what I exactly don&#39;t expect from a standard: to be left with this choices. When people read my markdown and when I read other peoples texts, I rather want us to use the same conventions.</div>
<div>And more important for me was the other &quot;freedom&quot; I mentioned: that there is no standard file extension. I did spend one or two hours trying to find an answer to which extension I should use for my own texts. And not only did it waste my time, this ambiguity really makes my life more difficult, because the tools I wrote don&#39;t know how to deal with it.</div>
<div><br></div><div>What you call &quot;flexibility&quot; will lead to the same problems, that many mainstream programming languages suffer from. When they grow from tiny tools to big systems and communities, people ask for standards. And then, all these &quot;good style&quot; recommendations need to be agreed upon and have to be learned on top of the syntax itself. What you call &quot;flexibility&quot; is counter-productive in standards and as a general feature, it is a misunderstanding of the way a formal language works in time.</div>
<div><br></div><div>Well, Markdown is a nice design. And, as I said, the few &quot;double standards&quot; might be well motivated and actually a good choice. And for the rest, Markdown is not ambiguous in principle. I used the &quot;.markdown&quot; extension in the past, and I probably stick to the habit until the Markdown community comes up with a decision and helps me out of my misery. ;-)</div>
<div><br></div><div><br></div></div>