[boerseth]

If the rules are too complicated, then they are a challenge for all parties, both users and implementers. I think it is useful to be able to imagine at least on some higher level what a parser would do to the stuff I write, so everyone benefits from the ease of understanding that comes with simpler rules. The question is just how far we can simplify without reducing usability.

The rest of the article frequently takes the side of the users, and mentions how confusing certain existing rules are to them. I know I frequently don't know what to expect from Markdown in certain corner cases, and felt vindicated by the author calling them out here. Some of their ideas for simplification would surprisingly even let us do things that are currently not possible.

[_gabe_]

> If the rules are too complicated, then they are a challenge for all parties, both users and implementers

Not necessarily. Generics, and/or C++ templates are a pain to parse because they're context sensitive. But while reading/writing code it's typically obvious whether I'm writing a comparison or a generic/template.

  Foo<Bar> foo;
  // VS
  Foo < Bar;

Likewise, in C++ you can end up with:

  unordered_set<tuple<int, float>> mySet;
  // >> is ambiguous here without a symbol table or context around the statement
  Foo >> 5;

I think both of these are fairly obvious as a user of the language, but boy am I glad I don't have to parse that!

[ilyt]

> If the rules are too complicated, then they are a challenge for all parties, both users and implementers.

You are still confouding rules for writing with rules for parsing. It's absolutely possible and easy to make rules making writing easier but parsing harder.

For example, if you make rule that makes formatting markers like **\_ be order insensitive (so **_word**_ formats same as **_word_**), much easier for user, as they don't need to remember order of which the operators were used, harder to code (I assume)