Hacker News Reader

Comment by pwdisswordfish | Hacker News Reader

Umm... why? The only rationale for this project I can see is this:

> Piping JSON through multiple programs creates lots of trivial changes, which makes it hard to do things like take meaningful diffs.

But you can always put JSON through a pretty-printer which puts values into canonical form before diffing. I wouldn't bother turning it into a formal specification. And you mention 'No insignificant whitespace' in the README, so it's not like your format makes line-by-line diffs any clearer.

It's as if IT hasn't had enough solutions in search of a problem...

View on HN

> I wouldn't bother turning it into a formal specification.

Too late!

> But you can always put JSON through a pretty-printer which puts values into canonical form before diffing.

Son is a starting point for building such a pretty printer. It takes care of messy details like eliminating the redundancies in string and number encoding, so all you have to do to specify the pretty-printer format is say where you want your newlines and how much to indent by.

> Son is a starting point for building such a pretty printer.

I don't understand: such pretty printers already exist (e.g. jq, which does a whole lot more [0]). If you're transmitting JSON and want to diff two documents, just pipe them into jq or another pretty-printer with key ordering, then use one of many existing line-by-line diff tools.

[0]: github.com/stedolan/jq

  $ echo "1." | jq .
  1

jq is great, but doesn't preserve float/int distinction. There may be other canonicalization details that pretty printers don't address.

It might be simpler to change jq and/or other pretty printers (though might be implementation or design reasons not to).

But the other advantage of a new project like SON is positioning not engineering, in our heads, not in the code: tool for the job. If so, the page should spend more time on what that job is (for when people search for that job).

And, as the jq example shows, tools not designed for this job mightn't do it exactly right.

EDIT I was reading offline, so didn't see the sibling reply.

I love that we both started our comments with "jq is great". I hadn't seen yours either=)

jq is great. You can actually see how it's used to test the reference implementation of Son here (https://github.com/seagreen/Son/blob/master/implementation/t...) using `jq --compact-output --sort-keys .`

Unfortunately, jq doesn't provide flags to control scientific/non-scientific notation or which characters are escaped, meaning if you want very tight control over the JSON generated it's not a full option.

(Consider that the motivating example in the Son README isn't all you might want to use Son for. For instance some people need consistent hashing of serialized JSON documents).

Ah, understood - thanks for clarifying!

Side note: I respect your positivity and steadfastness in the face of a skeptical HN response.

Sure thing. And thanks, that made me smile.

Reply on news.ycombinator.com