JSON is like the carcinization of programming

No, sir. That's an inline table, sir. That is clearly totally different, sir!

Chuck in comments and I'm on board.

If yaml didn’t have anchors and 8 different white space formats, it’d be a great replacement for this kind of thing.

But yaml is a mess, and you’d think you could parse it easily, but you can’t.

If we’re adding comments to json, can we add canonical support for trailing commas?

I think edn is almost the only more advanced and ergonomic option to json. Edn is like the evolved json, but its interesting that its roots are way older than JSON.

The fact that you can very efficiently define whole applications and software just with edn (and the lisp syntax in general) is what makes really amazing.

I think this blog post sheds more light on how we only need lisp for defining data and applications.

https://stopa.io/post/265

Found the python guy!

Oh, a trailing comma? That’s a tuple.

Is there any real reason why most progranming languages look more like the 3rd panel and not like the 1st panel? There's gotta be a reason for all the nesting and indents that has nothing to do with readability since that shit makes it harder to read.

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

Yeah when the call_func((a,)) is the way to go it is a newbie pain for sure. Remember banging my head on that one.

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.

TOML's design is based on the idea that INI was a good format. This was always going to cause problems, as INI was never good, and never a format. In reality, it was hundreds of different formats people decided to use the same file extension for, all with their own incompatible quirks and rarely any ability to identify which variant you were using and therefore which quirks would need to be worked around.

The changes in the third panel were inevitable, as people have data with nested structure that they're going to want to represent, and without significant whitespace, TOML was always going to need some kind of character to delimit nesting.

I’ve spent hours on that, and debugging missing commas between string literals. Even on separate lines you’re not safe from implicit concatenation.

import yaml :)

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.

Equals schmequals.
It could be a ⇨ and it would be the same as JSON because it is still a single symbol used as a separator.

a distinction without a difference

Now, if it took multiple separators, each giving some specific different meaning, then it would be a something else.

YAML is redeemed by one thing only:

All JSON is valid YAML.

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

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

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

Carcinisation is the phenomenon of non crabs to evolve crab like characteristics. It is not the process of non crabs becoming true crabs.

In this case the language is trending toward JSON syntax, but it doesn't have to actually be JSON for carcinisation to be an applicable analogy.

orange = {
    you = "glad",
    I = {
        didn\'t = {
            say = "banana"
        }
    }
}

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.

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.

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.

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

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

There just needs to be one universal standard that handles everyone’s use cases

Lazily-evaluated, too!

Time to read this if you haven't already

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

Just make JSON5 the new official version and I would be ok

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

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

Here is the grammar:

<json> ::=              <value> | <fn-def> <json>
<value> ::=             <object> | <array> | <string> | <number> | <bool>
                        | <fn-def> | <fn-app>
                        | "null"
<object> ::=            "{" [ <member> { "," <member> } ] "}"
<member> ::=            <string> ":" <value>
<string> ::=            "\"" { <char> } "\""
<char> ::=              (ASCII other than "\"", "\\", 0-31, 127-159)
                        | (Unicode other than ASCII)
                        | ( "\\" (
                            "\"" | "\\" | "/" | "b" | "f" | "n" | "r" | "t"
                            | "u" <hex> <hex> <hex> <hex>
                        )
<hex> ::=               /A-Fa-f0-9/
<array> ::=             "[" [ <value> { "," <value> } ] "]"
<number> ::=            <integer> [ <fraction> ] [ <exponent> ]
<integer> ::=           "0" | /[1-9]+/ | "-" <integer>
<fractional> ::=        "." /[0-9]+/
<exponent> ::=          ("E" | "e") [ "-" | "+" ] /[0-9]+/
<bool> ::=              "true" | "false"
<fn-def> ::=            "(" <ident> { <ident> }
                            ("->" <value> | ":" <string> <string>) ")"
<ident> ::=             <startc> { <identc> }
<startc> ::=            /A-Za-z_/ or non-ASCII Unicode
<identc> ::=            <startc> | /[0-9-]/
<fn-app> ::=            "(" <ident> { <value> } ")"
<var> ::=               "$" <ident>

carthinazation

It could be a ⇨ and it would be the same as JSON because it is still a single symbol used as a separator.

Nah, that's a Ruby Hash...

Yeah, it really is. A plaintext document that generates an entire OS?

As someone who works with YAML regularly:

Fuck YAML.

schmooby schmash

I think you've just invented Jsonnet, but with C integration.

https://jsonnet.org/

Excuse me, it's a Ruby Hash Rocket.

As if I didn't hate the format enough before

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

I’ve never had this issue with Python, but makefile has given me plenty of whitespace issues.

Should have added if it cares about tabs vs spaces.

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

As someone who runs Home Assistant:
Fuck YAML.