In JSON that datetime won't deserialize to a datetime instance in your language in a conforming parser. Further JSON has no comments (this is a killer for a configuration format).

There are ways to fake comments by using extra fields:

{ "what i want": "what i really really want", "ಠ_ಠ":"Ignore the eyes" }

I think you just helped Tom make his argument... :)

meteor has a way of serializing and deserializing datetime values http://docs.meteor.com/#ejson

In the authors own words[1]:

{ 'because': { '80': 'percent' }, {'of': 'JSON', 'is': 'brackets' } }

[1] https://github.com/mojombo/toml/issues/2#issuecomment-140029...

That's actually not valid JSON -- should use double quotes

{ "because": { "80": "percent" }, {"of": "JSON", "is": "brackets" } }

That's not valid JSON either! (The second value has no key). Needs to be:

{ "because": [{ "80": "percent" }, {"of": "JSON", "is": "brackets" }] }

And this is only 10% curly braces, not counting spaces.

Despite that, the thread easily illustrates the difficulty of writing valid JSON by hand.

JSON wasn't invented, it was discovered, from a long evolution of programming languages. The punctuation isn't ceremony. It's the amount needed for it to be concise (clear and terse, not just terse).

The difficulty level is hardly extreme. It is not an unreasonable challenge to learn that writing an array of elements requires opening and closing brackets.

The issue here might be that JSON has become widely used for two things:

   Data marshalling/transfer
   Config formats

For the latter, as they are typically written by hand, it's not particularly appropriate as the syntax is noisy and multiple nesting with brackets tends to lead to errors, even if you understand it perfectly well in principle, and of course there are no comments, no datetimes etc.

I imagine this is intended as a saner version of YAML for configs.

FWIW I've also recognized the problem and wrote and implemented my own configuration syntax, which makes the aforementioned JSON data look like:

[because=[[80=percent][of=JSON;is=brackets]]]

The implementation, which is in Haxe and has an informal spec in comments, can be seen here: https://github.com/triplefox/triad/blob/master/dev/com/ludam...

I didn't view bracketing as the enemy(which seems to be the focus of a lot of config syntaxes) but rather the combination of multiple types of bracketing, plus start-and-stop usage of shift keying. I only have two types of brackets, the sequence [ type and the long string {" type, and you can "feel" when you're writing a long string because of that sudden need to use the shift.

I've /never/ had a problem writing JSON by hand.

Try this in TOML:

key = "value1", "value2"

The same mistakes can be ignorantly made in any markup.