Live data from Hacker News

The Pretty JSON Revolution

ohler.com

51–60 of 159 posts

Re: The Pretty JSON Revolution

#52
post #10

I would prefer one that aligned the like named keys, if it fits in screen. Makes it dead easy to scan the values. That said, it is just another pun on the text as art thing. In that it doesn't really scale, and you are going to upset someone by not having a codified tool for automatically doing this. (I don't recall seeing align-regex in any popular tool.)

Can you explain what you mean by "like named"? The sorting helps a lot but I'm always interested in additional features.

I assume they mean vertical alignment like:

  [ { foo: a   bar: 123.45 }
    { foo: abc bar:   6.7  } ]

Re: The Pretty JSON Revolution

#54

Earlier quoted context omitted.

Just because the data is structured this way in the example, doesn't mean it's not possible. What's hindering you from defining a class property for each color? "colors": { "red":{"rgb":"fff"}", ... }

It's absolutely possible, yet the example doesn't do it. That's what the comment was calling out (plus a bit of superfluous "WTF").

What if you want to get the name for a hex color? Your "opinion" is just assumptions on how the data structure will be used, which you want to bake into the transmission format itself.

Re: The Pretty JSON Revolution

#55
I have trouble getting excited about tools to prettify JSON as long as the guy controlling the standard has a stubborn attitude about allowing comments or decent storage for long/multiline strings.

At this point I honestly take XML over JSON where I have a choice because of CDATA and comments.

Re: The Pretty JSON Revolution

#56
> JSON can be made prettier by sorting the JSON object members by element keys.

This seems to be a bad idea. The JSON language spec has ORDERED object members. But the order is arbitrary (precisely the one given in the JSON string) and does not have to be the lexicographic.

Sorting the object members by default would introduce problems whenever the order matters to the consumer of the JSON.

Re: The Pretty JSON Revolution

#57

Earlier quoted context omitted.

It is a stable sort since for almost every parser out there there can be no duplicate keys. It would be dangerous for an JSON parser to assume JSON object keys are in some specific order. It is certainly not something that can be counted on in golang, Ruby, or Python.

Also in violation of the spec: > An object is an unordered collection of zero or more name/value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. https://tools.ietf.org/html/rfc7159#section-1

The spec does call out that some parsers deal with this. And since it is javascript based, leniency is the norm.

That is, you could rely on this and but be aware of it, is my point. Firefox, for example, will happily take an object with duplicates and report only the last one.

Re: The Pretty JSON Revolution

#59
post #16

JSON is mostly for machines not people. When needed, developers format their json in their code editor of choice or bash.

JSON is mostly for people and not machines in that it is meant to be easily readable and editable by humans. If you wanted a something for machines you would store your data in a compressed/binary format.

Which demonstrates that JSON is pointless.

It's too ugly for humans (too many quotes, too many escape characters, and no comments) and too texty for machines.

Re: The Pretty JSON Revolution

#60
I tried using a json pretty printer in the lisp pp family of pretty printers (but it didn’t have miser mode.) Maybe we were just formatting things wrong and should have put brackets or breaking rules in different places, but changing that sort of code is hard and the results weren’t particularly great and people preferred the standard JSON.print(_,null,2) method. We switched to this and it was simpler and better. This format is also easier to process with something like grep or sed or awk or editor macros when needed.
Post reply on HN