undefined | Better HN

0 pointstgv7mo ago0 comments

Well, JSON cannot represent dates (nor Sets, Maps, NaN, etc.), so quite a few applications with a JSON parser have their own conversion (e.g. seconds since epoch, string parsing, object with date fields). Is that a bespoke JSON dialect that scares the pants off?

Now, JSON is more suited for machine-to-machine, but YAML works fairly well for humans. It's a pity, but a few domain specific don't really hurt, since you can't copy some bit of YAML and paste it in an entirely different config anyway.

PS campfire story? "When we were still working in the old building, deep down in the cellar, there was a colleague who had been there since the early days. Nobody saw him arrive at work or leave. It was as if he was always there. One of the things he had written was a custom parser ... FOR YAML!"

0 comments

maxbond7mo ago

I'd say that isn't a JSON dialect because that's postprocessing applied after parsing, versus hooking into a YAML parser to change the semantics of how `no` is parsed. But it is a good point.

I did run into a project once with a very cool custom YAML parser to recommend how to recover from errors. I think you do have to type check all deserialization, and you should fail if you process a bool where you expect a string. Automatically fixing things can be very dangerous. But if you were going to do it, the way you described is the best way to do it.

> Well, JSON cannot represent ... NaN ...

Here's another horror story:

    >>> # Python 
    >>> json.dumps({"foo": float("nan")})
    '{"foo": NaN}'

    > // JavaScript
    > JSON.parse('{"foo": NaN}')
    Uncaught SyntaxError: Unexpected token 'N', "{"foo": NaN}" is not valid JSON

j / k navigate · click thread line to collapse