Discover the magic of the internet at Imgur, a community powered entertainment destination. Lift your spirits with funny jokes, trending memes, entertaining gifs, inspiring stories, viral videos, and so much more from users.
Serializing? For serializing you probably want performance above all else. I’m saying this without checking any benchmark, but I’m sure yaml is more expensive to parse than other formats where indentation don’t have meaning.
For human readability: it has to be readable (and writeable) by all humans. I know (a lot of people) that dislike yaml, toml and XML. I don’t know of a single person that struggles to read/write json, there is a clear winner.
JSON would be perfect if it allowed for comments. But it doesn’t and that alone is enough for me to prefer YAML over JSON. Yes, JSON is understandable without any learning curve, but having a learning curve is not always bad. YAML provides a major benefit that is worth the learning curve and doesn’t have the issues that XML has (which is that there is no way to understand an XML without also having the XSD for it)
If a comment isn’t part of the semantic content of a JSON object it has no business being there. JSON models data, it’s not markup language for writing config files.
For the data interchange format, comments aren’t part of the JSON grammar but the option to parse non-JSON values is left open to the implementation. Many implementations do detect (and ignore) comments indicated by e.g. # or //.
I’ve disagreed with JavaScript before, what makes you think I won’t do it again?
Anyway, anything using JSON as a config language will also certainly use a JSON interpreter that can ignore comments. Sure that’s “implementation specific,” but so is a config file. You wouldn’t use “MyApplication.config.json” outside the context of MyApplication loading its own configuration, so there’s no need for it to be strictly compliant JSON as long as it plays nicely with most text editors.
Serializing isn’t necessarily about performance, or we’d just use protobuf or similar. I agree Json is a great all rounder. Combine with JSON object schema to define sophisticated DSLs that are still readable, plain JSON. TOML is nice as a configuration language, but its main appeal (readability) suffers when applied to complex modeling tasks. XML is quite verbose and maybe takes the “custom DSL” idea a little too far. YAML is a mistake.
I don’t know why we’re fucking about trying to use text editors to manipulate structured data.
Yeah, it’s convenient to just be able to use a basic text editor, but we’re not trying to cram it all on a floppy disk here. I’m sure we could have a nice structured data editor somewhere for all those XML, JSON and YAML files we’re supposed to maintain every day.
Serializing? For serializing you probably want performance above all else. I’m saying this without checking any benchmark, but I’m sure yaml is more expensive to parse than other formats where indentation don’t have meaning.
For human readability: it has to be readable (and writeable) by all humans. I know (a lot of people) that dislike yaml, toml and XML. I don’t know of a single person that struggles to read/write json, there is a clear winner.
JSON would be perfect if it allowed for comments. But it doesn’t and that alone is enough for me to prefer YAML over JSON. Yes, JSON is understandable without any learning curve, but having a learning curve is not always bad. YAML provides a major benefit that is worth the learning curve and doesn’t have the issues that XML has (which is that there is no way to understand an XML without also having the XSD for it)
Json should also allow for trailing commas. There’s no reason for it not too. It’s annoying having to maintain commas.
And also a standard date time type!
What is wrong with ISO 6801 strings?
11-2023-14
I dunno it just kinda looks weird to me
Dunno what format you’ve got there, but ISO 6801 looks like
2023-11-15T18:28:31ZIt’s a joke, because the standard is 8601, not 6801.
Oh. Egg on my face then lmao I didn’t even notice
JSON5 has comments, among fixing a few other shortsighted limitations of the original.
If a comment isn’t part of the semantic content of a JSON object it has no business being there. JSON models data, it’s not markup language for writing config files.
You can use comments in JSON schema (in a standardized way) when they are semantically relevant: https://json-schema.org/understanding-json-schema/reference/comments
For the data interchange format, comments aren’t part of the JSON grammar but the option to parse non-JSON values is left open to the implementation. Many implementations do detect (and ignore) comments indicated by e.g. # or //.
JavaScript package management promptly said otherwise. JSON is a config format no matter if you like it or not.
I’ve disagreed with JavaScript before, what makes you think I won’t do it again?
Anyway, anything using JSON as a config language will also certainly use a JSON interpreter that can ignore comments. Sure that’s “implementation specific,” but so is a config file. You wouldn’t use “MyApplication.config.json” outside the context of MyApplication loading its own configuration, so there’s no need for it to be strictly compliant JSON as long as it plays nicely with most text editors.
Really? Any JSON over 80 chars becomes a nightmare to read for me, especially if indention is not used to make it more readable.
Serializing isn’t necessarily about performance, or we’d just use protobuf or similar. I agree Json is a great all rounder. Combine with JSON object schema to define sophisticated DSLs that are still readable, plain JSON. TOML is nice as a configuration language, but its main appeal (readability) suffers when applied to complex modeling tasks. XML is quite verbose and maybe takes the “custom DSL” idea a little too far. YAML is a mistake.
I don’t know why we’re fucking about trying to use text editors to manipulate structured data.
Yeah, it’s convenient to just be able to use a basic text editor, but we’re not trying to cram it all on a floppy disk here. I’m sure we could have a nice structured data editor somewhere for all those XML, JSON and YAML files we’re supposed to maintain every day.