> Many language require strings to be quoted

The languages we're comparing here are JSON and YAML. The latter does not require quoted strings, except in ambiguous cases. (And even then, actually, it technically isn't required, though it is usually the easiest thing to do.) The absence of these quotes makes the syntax get out of the way of the reader, and makes YAML comparatively easier to read.

> comma requirements inane is an opinion, not an objective fact.

I boiled it down to a simple statement, but disallowing a comma at the end of repeated grammars means that adding something to that line causes unnecessary noise in the diff. For example, say I add a single item to the end of a JSON list. The diff I would love to see is:

   [
      a,
      b,
  +   c,
   ]

which makes it rather straight-forward to the code reviewer / reader of the diff that we're simply adding a single item c. But JSON's grammar forces this diff:

   [
      a,
  -   b
  +   b,
  +   c,
   ]

which makes it harder to see what the semantic change is, because simple syntactic changes are now clouding the picture. Also, I find that people's mental model of the task ("add item to end of list") causes them to forget that they need to add a comma to the item above it, resulting in syntax errors down the road.

(Better diff tooling can help here, but often I find we have to work with the most primitive of tooling; if the grammar can lend itself towards such simple tooling, s.t. that tooling is more effective despite its simplicity, why not? And here, we can: grammatically, whether the list ends or does not end in a comma is rather meaningless, and JSON (and for a long time, JS) were pretty alone in this opinion. Most other languages allow that trailing comma. The only other one I can think of is SQL.)

> You're not saying anything about the readability of one versus another, you're just listing gripes you have about JSON.

The gripes I have about JSON don't apply to YAML. Hence, that's why I prefer using YAML, which was the original question.

> The latter does not require quoted strings, except in ambiguous cases.

I believe it is the right choice to always quote strings, there should be various quoting formats as no single one is perfect (normal strings with reasonable escapes,raw string, multiline-with-indentation, multiline raw strings...) and you should be able to use unquoted keys (TOML has a good balance on this problem), but unquoted strings as a default are unnecessary and problematic.

You post a comment describing one alternative as "simpler" and "easier to read" compared to another.

Respondent lists five specific reasons in support of the opposite conclusion.

You dismiss those as "opinions, not objective facts". Ignoring that the same could be said for your parent comment, to a much greater degree.

No comments is... fair. That does put a limit on the legibility of JSON files, unless you want to count dumb hacks like comment strings.

Having to quote strings in JSON, however is still simpler than the multitude of ways strings can be declared in YAML. You know a string is a string in JSON because of the quotes... knowing whether something is a string or not in context is more difficult in YAML because of the more complex syntax.

You can learn the entire syntax of JSON in minutes. Objects, arrays, string keys, and a few primitive types... that's it. How long would it take to learn all of YAML? How explicit is its syntax versus JSON? Of course JSON is far simpler, and being simpler, it's easier to read.

I dismissed "inane comma requirements" as an opinion, not everything the commenter said. The only reason it's "inane" is because the commenter doesn't like it personally.

Not having multiline strings, to me, doesn't affect readability much at all, although it is unfortunate. Turn on text wrapping in your editor, it's the same thing.

Typing support doesn't affect readability either. I'd like to have a date type in JSON too but

    2013-03-01T16:15:09+01:00

or whatever is just as readable as

    "2013-03-01T16:15:09+01:00"

Parent's points are exactly the reason I'd never consider JSON as config format.