71–80 of 412 posts
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.
Or pipe through json5 which has other conveniences one might want like trailing commas.
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…
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?
Semirandom question: what's the proper file extension for a YAML file? I've done informal polls on it and every time it's an even split between .yaml and .yml
There are plenty of file formats that have multiple extensions in common use. I can think of a few off the top of my head: - .jpg / .jpeg - .tif / .tiff - .htm / .html - .cpp / .cxx It's frustrating at times, but not all file formats have One True Extension.
With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…
> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.
What about Toml , I like it. https://github.com/toml-lang/toml
Earlier quoted context omitted.
> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.
>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.
YAML and TOML both seem too complicated. Automatic date parsing? So many different ways to specify the same nested hash table? I like json because there's usually one obvious way to do what you want. It's a local minimum, like C and Lisp. It's really too bad about the comments.
Earlier quoted context omitted.
There are plenty of file formats that have multiple extensions in common use. I can think of a few off the top of my head: - .jpg / .jpeg - .tif / .tiff - .htm / .html - .cpp / .cxx It's frustrating at times, but not all file formats have One True Extension.
C++ is the worst offender: .cpp, .cxx, .cc, .h, .hpp, .hh, etc.