Hacker News Reader

Comment by tzury | Hacker News Reader

    Because we need a decent human readable format 
    that maps to a hash and the YAML spec is like 
    600 pages long and gives me rage. No, JSON 
    doesn't count. You know why.

I do not know why, And would love if one can explain me?

Other than comments, I see not difference between both.

Also, that human readable is not an accurate, as it should be hacker readable, you know, IT folks are the only target audience of those files.

    [owner]
    name = "Tom Preston-Werner"
    organization = "GitHub"
    bio = "GitHub Cofounder & CEO\nLikes tater tots and beer."
    dob = 1979-05-27T07:32:00Z # First class dates? Why not?


    {
        "owner": {
            "name": "Tom Preston-Werner",
            "organization": "GitHub",
            "bio": "GitHub Cofounder & CEO\nLikes tater tots and beer.",
            "dob": "1979-05-27T07:32:00Z"
        }
    }

View on HN

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.

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.

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).

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.

Reply on news.ycombinator.com