81–90 of 412 posts
If your configuration file is so long it's unreadable in YAML, then maybe you need to break it up into more than one file? I can't imagine any syntax would be easy to read once you reach more than 100 or so lines.
Do any configuration file languages support type hinting? Adding (int) in front of a YAML key would be easy enough to read, and would keep some of the confusion at bay.
Earlier quoted context omitted.
Or pipe through json5 which has other conveniences one might want like trailing commas.
I love json5, but it's not always an option.
We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.
XML is in that odd middle-ground where it's usually human-readable, but also a huge pain in the ass to write. It's great at what it was intended for, as a data interchange format. For a general-purpose human-writable structured data format, I guess the ugly nonstandard hack that is "JSON with comments" is probably good. It's certainly faster to parse than YAML.
It may seem that way, but it's not. Re: cryptographic functions
First of all, don't ever try to edit a YAML file by hand. You will introduce whitespace or other characters that will break the file, and you will not know until you run it and it breaks something.
The reason you will not know? Not all YAML parsers are the same. Some will interpret it correctly, and some will break. You'll have to get reference implementations of every "supported" YAML parser and run every config you have through them all, and diff them all, before you can trust them.
YAML may be easier to read than JSON, but its added complexity (the parser is significantly more complicated) and obtuse "features" are just not worth the effort. Not to mention, have you ever tried to maintain a very large indented YAML file by hand? Pain in the ass. Just shove everything into JSON files. The fact that it's so limiting is freeing, and everything can parse it. But don't edit it by hand.
And IMNSHO, you shouldn't use either YAML or JSON as a configuration language. They are for data structures, not configuration. If you want a configuration language, go get something designed as a configuration language.
One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…
> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?
> The primary objective of this revision is to bring YAML into compliance with JSON as an official subset.
I agree with some of the author's points but the "surprising behaviour" section is odd. For example, why would you expect `3.5.3` to be parsed as a number? How could that be parsed as a number?
The 013 to 11 issue is pretty obvious to any seasoned programmer. For example C, Ruby, and yes, also Javascript have the same "problem". Octal 13 is decimal 11. JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'. And YAML is backwards compatible to JSON. That's IMO the actual problem of YAML. It could have supported a reasonable subset of JSON and not the whole…
Also JSON doesn't treat a 0 prefix on a number as special. There are no octal (or hex) literals in JSON. In fact, a JSON number literal cannot even start with 0 unless that's the only digit (before the period), e.g. 013 is not a valid numeric literal in JSON.
One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…
Earlier quoted context omitted.
>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. -Douglas Crockford, creator of JSON There is no issue using JSON with comments for a config file.
Blurg, now every tooling pipeline that uses JSON needs to include a JSMin step...
/\/\/.*/gm
We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.
Safety? The OWASP Top 10 doesn't feature a JSON security issue. https://www.owasp.org/index.php/Top_10-2017_A4-XML_External_...