4 ms·

JSON is horrible for a configuration language. Needing to put quotation marks around every single literal is insanely irritating if you ever have to write a lo

by librvf 11y ago

JSON is horrible for a configuration language. Needing to put quotation marks around every single literal is insanely irritating if you ever have to write a lot of configuration. There's also a lot of application-specific syntax sugar that you cannot do if you stick with strict JSON. Note that it's not really fair to call Apache's configuration language "XML". Apache relies on XML for some structured data in its configuration file, but all the individual directives are parsed separately from the XML.

nikolay 11y ago
I agree. When people started to move towards the "better" JSON standard from XML, I was puzzled. The inability to have comments, the need to "escape" every key name, the lack (in the past) of a schema and query language standard, etc.
- librvf 11y ago
  To be fair, while I agree that JSON is bad for config, I would argue that JSON's objects and arrays eliminate the need for DTDs and standard query languages altogether in many cases. Of course, with sufficiently lqrge and complex data stores, you'll want a documented structure and method for accessing that data no matter what format you use, but unlike XML, JSON provides structure to get started on a small scale very easily. Consider this python: import json import sys sys.stdout.write("%s\n" % json.dumps(json.load(sys.stdin).get(sys.argv[1], None))) This will accept JSON on standard input and will return the value of an object with the key name specified by the first command-line argument. $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value1 {"sub-value": 5} $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value2 99 Such a program will look similar in any language with a json library that maps objects and arrays to native data structures. Granted, my simple tool will fail if the JSON isn't an object, but it's a very simple matter to extend it to handle lists and literals. For many applications this is a huge advantage over XML, especially if the point of the JSON isn't configuration but rather inter-application communication (aka data serialization).

by librvf 11y ago

nikolay 11y ago

I agree. When people started to move towards the "better" JSON standard from XML, I was puzzled. The inability to have comments, the need to "escape" every key name, the lack (in the past) of a schema and query language standard, etc.

librvf 11y ago
To be fair, while I agree that JSON is bad for config, I would argue that JSON's objects and arrays eliminate the need for DTDs and standard query languages altogether in many cases. Of course, with sufficiently lqrge and complex data stores, you'll want a documented structure and method for accessing that data no matter what format you use, but unlike XML, JSON provides structure to get started on a small scale very easily. Consider this python: import json import sys sys.stdout.write("%s\n" % json.dumps(json.load(sys.stdin).get(sys.argv[1], None))) This will accept JSON on standard input and will return the value of an object with the key name specified by the first command-line argument. $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value1 {"sub-value": 5} $ echo '{ "value1" : { "sub-value": 5 }, "value2": 99 }' | python json-test.py value2 99 Such a program will look similar in any language with a json library that maps objects and arrays to native data structures. Granted, my simple tool will fail if the JSON isn't an object, but it's a very simple matter to extend it to handle lists and literals. For many applications this is a huge advantage over XML, especially if the point of the JSON isn't configuration but rather inter-application communication (aka data serialization).