I love JSON. But I really wish there was a standard that allowed commas with no following items and that there was a syntax for comments.

That’s not JSON. Note the use of equal signs for the property names. That’s something else.

What’s it called when people try to reinvent Lisp for the hundredth time?

Chuck in comments and I’m on board.

Just the other day I had a list show up as [“a”, “b”, “c”, “d”, “e”, false, “g”, “h”, “i”].

The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.

Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd “rare” bugs.

I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I’ve always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).

Significant white-space is bullshit and i will die on this hill.

Once you’re used to it, indentation makes code soooooooo much easier to read. When I was in school and a classmate asked me for help with their code, I outright refused to touch it until they properly indented it. It makes it easy to see the structure.

For programming languages that make use of {}, the reason is (almost always) scope.

Take for instance this:

for i in 0..10
do_thing();
do_other_thing();

compared to this:

for i in 0..10 {
    do_thing();
}
do_other_thing();

The intent of the first one is unclear. In the second one it’s clear you should loop do_thing() and then run do_other_thing() afterwards. The indentation is only for readability in the above though. Logically there would be no difference in writing

for i in 0..10 { do_thing(); } do_other_thing();

Languages that use indentation and line breaks for scope look more similar to this:

for i in 0..10:
    do_thing()
do_other_thing()

Because the 3rd panel looks better when you have dozens of physical properties to track. It also makes retrieval easier because you can get all the physical properties at once, instead of having to read every line.

For an example that small it doesn’t matter, but for something larger it could become a performance benefit.

I would guess that it has to do with making it easier to parse. The indents won’t matter very much, but the parser sees "physical = " and knows that a property named physical is being defined. What is the value of that property? Well, there’s a “{”, so the value is an object. And the value of that object is everything up until the matching “}”. If you have a structure more like panel 1, then it’s harder for the parser to know when the value of orange.physical is complete. There might be a [orange.physical.texture] section somewhere, for example.

since that shit makes it harder to read

It makes it harder to read the individual lines, but makes it easier to read them as a group, so you won’t have to read as many lines on your day to day.

A good way to feel that for yourself is by programming a little program in Assembly and C.

Make sure the program needs to loop a bit and perhaps also require some if/ else logic.
A simple one would be to read a 1000 integers and return the sum.

In C, you would do something like:

int MAX = 1000;
int accumulator = 0;
int counter = 0;
while (counter < MAX)
{
    accumulator = accumulator + value_at_next_memory_location_by_counter;
    counter = counter + 1;
}

In assembly, you would go (writing pseudo, because I have forgotten most assembly stuff):

set reg1 = 1000 // For max value
set accumulator = 0 // just choose a register and consider it an accumulator. older CPUs have a fixed accumulator and you can only operate on that. I am not considering that here
set reg2 = 0 // For counter
tag LOOP:
set flag if true reg2 < reg1
jump if false -> END
move from memory location @counter(reg2) to reg3
add accumulator reg3
add reg2 1
goto -> LOOP
tag END:

I also realised that you could just try using C with goto instead of any loops and would realise similar things, but I’m not in the mood to rewrite my comment.

In conclusion, it is easier to understand something like BASIC, if you haven’t been introduced to other languages, but these {} structures end up making it easier to catch control flows at a glance.
That’s also the argument I use when telling people to have opening and closing brackets of the same level at the same indent, while people prefer stuff like:

if {
...
} else {
...
}

Almost all of those issues are solved by explicitly quoting your strings, the author even acknowledges that. Yeah it’s annoying that yaml lets you do otherwise, but the title is a bit dramatic.

YAML is redeemed by one thing only:

All JSON is valid YAML.

I have a fundamental disdain for formats with restrictive white space definitions (I’m looking too at you Python)

As someone who works with YAML regularly:

Fuck YAML.

I want to like yaml, I really do, but why are there so many different ways of specifying the same thing?