51–60 of 412 posts
Earlier quoted context omitted.
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
Python dicts are a lot closer to JSON than YAML. The real schism here, IMO, is Programmer Intuitive vs. Natural Language Intuitive.
Earlier quoted context omitted.
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
I actually use Python a lot more than Javascript. That's why the double quotes and the no trailing comma are always what get me. Especially since leaving the trailing comma is considered the best practice in every other language.
Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.
If I don't enjoy a movie, I'm under no obligation to suggest another. It's an opinion. It can stand alone.
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.
{ "ConfigKeyComment": "This is for blah blah blah", "ConfigKey": "Foo" }
Obviously this wouldn't work in all cases (you're putting more work on your parser to interpret unused keys basically), but if we're talking config files specifically, I see this as an acceptable approach since there's little chance you'll be parsing such files more than once each (plus, writing a simple tool to strip the comments out would be very trivial).
> Are you sure that every YAML parser will treat foo:bar as a string, or 0x42 as the integer 42, etc.? Definitely not. I'd expect 0x42 to be 66. (Not kidding, if 0x42 means hex notation!). Point taken.
XML -> doesn't record what programs think of as 'data'. So a program needs to convert it's data representation to XML and back again. Usually there is no formal spec. This is the exact same issue you have with databases. But at least a database has a formal representation and data types.
Part of SOAP is Microsoft trying to bolt schema's onto XML. SOAP seems to generate a lot of unhappy programmer noises. But my ex roommate said, 'well when you get it working it works'
JSON and YAML do but they don't have schema's to parse against. So programs need to do their own validation.
Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.
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.
-Douglas Crockford, creator of JSON
There is no issue using JSON with comments for a config file.
Earlier quoted context omitted.
You use JavaScript a lot more than python, right? Intuitive usually means "close to what I'm used to".
Python objects and JSON are practically identical.
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.
> 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.