I don’t feel like it will stray very far from what’s dubbed “TOML 0.1” in the meme. Yes, it has inline tables and as of TOML 1.1, they’re allowed to span multiple lines, so it’s technically not anymore illegal to do what’s in the meme. But all things considered, this is still a miniscule change compared to TOML 1.0.

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

I was such a menace with this joke as a child. Haha

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.

As if I didn’t hate the format enough before

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.

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

Well…

It’s name-value pairs, with groups denoted by balanced brackets. It’s close to as good as you can get for one kind of data serialization.

What is impressive is how many problems people manage to fit in something so small.

Chuck in comments and I’m on board.

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

As someone who works with YAML regularly:

Fuck YAML.

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)

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

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

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.

https://en.wikipedia.org/wiki/TOML

Sounds like Nix is a pathway to many abilities I consider to be unnatural.

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" "jenn.craig.420@hotmail.com"),
    (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.

Lazily-evaluated, too!

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.

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.

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.

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

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