YAML is redeemed by one thing only:

All JSON is valid YAML.

I’m a fan of NestedText. It’s no panacea but I’d argue it’s the most well-considered and useful file format for structured data in plain text.

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

As someone who works with YAML regularly:

Fuck YAML.

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

I’m a daily Clojure user, and I knew immediately where that article was going, but it was still a delightful and insightful read! Thanks for sharing!

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.

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.

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

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();

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. Languages that use indentation for scope look more similar to

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

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.

Lazy devs going the easy way and not fixing their structural issues.

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.

Well, Wikipedia does say:

The [TOML] project standardizes the implementation of the ubiquitous INI file format (which it has largely supplanted[citation needed]), removing ambiguity from its interpretation.

en.wikipedia.org/wiki/TOML

Lazily-evaluated, too!

It’s basically just JSON that can generate itself !

You have inspired me.

I will make JSON with meta-programming

I will call it DyJSON, i.e. “Dynamic JSON” but pronounced “Die, Jason!”

It is JSON with meta-programming and the ability to call C functions from libraries

Example:

# This is a line comment # Put your function definitions up here (concat str_a str_b: "concat" "my-lib.so") # Import a function through a C ABI (make-person first_name last_name email -> { # Define our own generative func "name": (concat (concat $first_name " ") $last_name), "email": $email }) # And then the JSON part which uses them [ (make-person "Jenny" "Craig" "[email protected]"), (make-person "Parson" "Brown" null) ]

As you can see, it is also a LISP to some degree

Is there a need for this? A purpose? No. But some things simply should exist

Thank you for helping bring this language into existence

I had the same thought. At panel 3 it’s just oh that’s nix with commas.

good thing nixers do not know the art of lisp

As if I didn’t hate the format enough before

The json spec is not versioned. There were two changes to it in 2005 (the removal of comments

See, this is why we can’t have nice things.

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.

Iceland mentioned 🇮🇸

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