Writing YAML is not easy for end-users. The indentation--especially in large files--is really difficult to keep track of, and some really basic stuff like when to quote strings is not consistent at all.

It definitely is. You have no idea how intimidating an equivalent JSON file would be for a new user creating a pretty simple k8s setup.

YAML hides most of the scary brackets and quotes so that new users can focus on copy-and-pasting semantic tidbits.

That said... I don't like YAML...

Nope, indentation is not a problem with indentation guides. A misplaced comma in a JSON file however kills it, gets me every time I have to write it by hand.

Also, it is true YAML has too many features, though I find they are typically ignored or disabled.

A misplaced comma is also not a problem in an editor with syntax highlighting, but between the two, indentation could take longer to fix.

Syntax highlighting doesn't count commas. The problem is JSON doesn't allow trailing commas, so adding or reordering frequently results in a difficult to diagnose error.

Finding out if a set ends in a comma or not still makes it easier to debug than YAML.

Not my experience, 10x more trouble with long JSON.

But the simpler format of JSON should be easier to write and read.

No comments, constant need to quote every string, inane comma requirements, no multiline string, little typing support.

Many language require strings to be quoted, and calling the comma requirements inane is an opinion, not an objective fact.

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

> 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.

Not when you take into account all the clutter in JSON: braces, brackets, quotes. Those are extra things to type and extra things to have to filter out when you read.

See sibling comment.