Visual clutter, familiarity to non-coders. Curly braces are almost never used outside of programming and are ugly to boot.

My benchmark for yaml/JSON alternatives is "how would I feel explaining it to a busy, sceptical client?"

If the intended audience is purely developers, then sure. JSON (with the addition of comments and trailing commas) is just fine.

White space has the additional advantage of agreeing with itself. Other demarcations can have issues where the indentation and the structure contradict each other.

Again the dreaded Cobol argument. We had to struggle with a lot of this in the past: Cobol, SQL, YAML, BDD. All this would be much easier without this nonsensical idea that nontechnical people will read code. They won’t. Making code a bit more like prose doesn’t make it readable for nontechnical people. Yet we again and again make our life harder - ugly syntax rules, no code completion, no auto-formatters.

Please stop making code easy for non-coders. They don’t want to read it. They never did. They just want this damn box to work.

as a counter argument. I work in robotics, where many operators will look at and change settings in a yaml file during testing. They do not have software skills outside of this.

My educated guess then is you could have gotten them to change "settings" in C, Java or basically anything.

Just put the file in the root folder, and keep it as simple as possible and you should be fine? I mean, if they manage to write yaml correctly and consistently C is no match?

maybe? the dynamic loading of the configs kind of restricts it to a markup language.

The reason the situation is the way it is now is precisely because the code being made easy for non-coders increased the popularity and reach of the products. Probably because non-coders also found it easy to pick up and start working with it.

Wrong use case. I'm talking about asking them to write it edit these files.

I haven't found "this needs to be indented exactly the right amount or it won't work" to be much easier for non-programmers than "this needs to be enclosed in braces or it won't work." Most people have at least experienced parentheses in math (albeit maybe decades ago), so it's not an entirely foreign concept. Either one requires a bit of learning, but I think most people are capable of it, so any improvement in non-coder familiarity seems minor at best, vs. the very real costs.

Counter-argument - why do programmers insist on clear indentation if it doesn't aid readability? The indentation is there for humans and the braces are there for the compiler.

That's why you have both and lint against inconsistencies. This catches errors.

>My benchmark for yaml/JSON alternatives is "how would I feel explaining it to a busy, sceptical client?"

My benchmark is this: can an autoformatter do its job every time without breaking something that's technically working right now but possibly formatted wrong?

Every data format that cannot comply with this contains in it a huge waste of time. Even as a python programmer, I extend the same rule to programming languages.

Significant whitespace is evil. It's just begging for copy/paste bugs.

Funny that's never been an issue for me after 2 decades of writing Python.

My google ability didn't see anything, but are their any case studies that show it's more readable? I'm happy to accept that it is, but I can't help wondering if research has been done or it's mostly gut feeling / anecdotes / aesthetics.

> that show it's more readable?

I'm not clear exactly what the "it" here refers to but as I mentioned in other comments it's fairly self-evident that indentation is easier to visually parse than braces. A simple thought experiment - would you find it easier to skim read code where the indentation was consistent with the bracing or where it was inconsistent? Your brain registers the indentation first and you only resort to counting braces if there's a reason to doubt the former.

Reality often times runs counter to our expectations though, which is why I wondered if no brace methods have been shown to enable simpler to understand usage / understanding.

My point was that the debate is between "indentation alone is sufficient" and "braces plus indentation is better than just indentation".

Nobody advocates for "braces are better without indentation".

This surely implies that (practically) everyone agrees indentation is carrying most of the weight of visual indication of structure.

Of course "everyone" might be wrong - but that's a fairly tricky corner to defend.

> Nobody advocates for "braces are better without indentation".

^^^ THIS ^^^

That's just display though, if you have to show it to a skeptical client, why not run it through a browser that shows it without braces? It's the same as showing a webpage instead of the html.

I was specifically thinking about asking clients to edit or write these files. Isn't that a fairly common use case for config languages?

If programmers find getting YAML indentation correct difficult how are non-programmers going to fair?

If the HomeAssistant subreddit is anything to go by its their biggest complaint (HA configuration is in YAML).

With that said if they weren't complaining about white space they'd be complainit about missing semicolons, missing/extra commas, missig equals signs, missing closing )]} or whatever.

Are you arguing "braces are easier to get right than indentation" or is this a point specific to YAML's rules? Because I'm not defending the latter but I find it hard to understand I would need to argue against the former.

That's a good point someone brought up in a different comment. I haven't really dealt with those scenarios, so honestly I'll accept that as a reason.

I wish it could be displayed with braces though, I wonder if someone already has built that as an extension for editing / viewing yaml files.

YAML is a superset of JSON. In other words: any syntactically valid JSON file is a valid YAML file. If you want braces like JSOM, but not quoted strings, YAML supports it.

> YAML is a superset of JSON.

That's false. http://p3rl.org/JSON::XS#JSON-and-YAML

You could run a formatter which adds braces if you like?

This makes zero sense to me. Why do config files out of all things have to be accessible to non-coders?

Because we are asking them to write these things in many cases.

I'm not buying that you genuinely have a target audience of "I trust this person with config files but their eyes are too gentle to see a curly brace".

Well. I've genuinely had clients editing YAML so there's that.

I can definitely think of a broad range of people where I'd be happy to recommend they use text files for config and data but I wouldn't be happy if those text files needed to follow the rules of JSON syntax.

I mean - to some extent I would rather not edit JSON. It's not a terribly ergonomic experience. If I had to design a format for my own use, it would be indentation based and probably look a little bit like YAML, Markdown or similar.

Because they're not code?

Isn't an indent a clear demarcation?

Not at all.

If it was code, an indentation error would often not compile or show errors or fail tests.

Configuration in YAML is much worse: most of the time an indentation error goes undetected until an application starts misbehaving.

Significant whitespace is perfectly ok for code but a huge footgun for YAML

Literally, yes.

But I find it incredibly annoying to estimate indentation when lines are wrapped in an editor (or webpage). Or, to a lesser extent but still throws me off, when multiple blocks end at the same line. Or when pasting blocks into another block, and having to double check to make sure the indentation was carried over correctly. I like editors that visually show indentation characters.

Only if you forbid tabs ...

If it must be created by non-programmers too delicate to match braces, how about BEGIN .. END and an autoformatter.

Or, NODE <name> .. END .

tabs or spaces for that indent?

it makes a difference on how it is parsed, so it's more than a devs preference

It really doesn't matter. Just force the leading indent to be exactly the same bytes. If indent moves between two values where one isn't a prefix of the other raise an error.

is one \t the same as \s{4,} in bytes? that doesn't make any sense

No it isn't. That is the point. If you have one line indented with 4 spaces and one line indented with a tab there is no correct answer what the difference of indent is. The only good option is to raise an error.

right, or encapsulate in some sort of braces ;-)

Sure, that is another option. But your code still looks confusing.

Personally I mostly use indent to read code, so requiring that the indent matches the semantic nesting makes it much easier for me to understand.

Looks confusing to who? Another coder? Then they have issues.

I get the original was talking about client facing config files. I'd rather see INI style config files personally.

If you're writing ugly code, braces or spaces won't save you. Just don't write ugly code.* Write it like the next person to view your code is an axe murder that knows where you live, so don't make them mad. You can minify later.

*I'm ignoring Perl, as it's always ugly

An underrated property of braces in this case is that a truncated document is no longer valid (assuming your document only has one top-level item).

Truncate YAML and in most cases you still have valid YAML.