orange = { you = "glad", I = { didn\'t = { say = "banana" } } }I was such a menace with this joke as a child. Haha
Time to read this if you haven’t already
https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
As if I didn’t hate the format enough before
JSON is like the carcinization of programming
What’s it called when people try to reinvent Lisp for the hundredth time?
carthinazation
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.
If we’re adding comments to json, can we add canonical support for trailing commas?
Found the python guy!
Oh, a trailing comma? That’s a tuple.
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’ve spent hours on that, and debugging missing commas between string literals. Even on separate lines you’re not safe from implicit concatenation.
Just make JSON5 the new official version and I would be ok
That’s not JSON. Note the use of equal signs for the property names. That’s something else.
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.
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.
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.
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.
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?
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.
import yaml:)
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.
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.
No, sir. That’s an inline table, sir. That is clearly totally different, sir!
That’s literally just lua tables
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.
