Live data from Hacker News

The Pretty JSON Revolution

ohler.com

141–150 of 159 posts

Re: The Pretty JSON Revolution

#141
post #24

Please: { "colors": [ { "color": "black", "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red", "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow", "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green", "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan", "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue", "hex": "#00f", "rgb": [ 0, 0, 255 ] }, { "color": "magenta", "hex": "#f0f", "rgb": […

Opinionated Opinion: That's an incredibly XML-ified version of a color table. I can clearly see the tags now. Can't just do a look up of a color color, instead I would have to iterate over the members or store it in a different data structure. Why even use JSON? Blech.

Perhaps the purpose is to list colors in a specific order, such as to show to the user in a desired order?

And before you argue that dictionaries can still be iterated in order, you better check the sibling threads where people are arguing you shouldn’t rely on that.

Re: The Pretty JSON Revolution

#142
post #135
post #84

Relevant plug: if Pretty Notations interest you, then you should keep an eye on Tree Notation https://treenotation.org/ .

The Tree Notation is like the opposite of pretty notation though, no? The whole idea of pretty notation is automatically inserting non-significant whitespace to make it look nice. Step 2, "one line per node", inserts spaces and newlines. Step 4, "human style" strategically removes some of those so the lines look nice -- the 2nd level dict has lots of content, so it was split across multiple lines... while the 3rd lev…

The OP is sort of all over the place (their favorite "Pretty JSON" is not actually JSON at all, but SEN, which is definitely not JSON, which has a very discrete specification).

So what they are really talking about is just pretty code. Their favorite examples utilize alignment (tree notation does that better—every tree doc is ismorphic to a spreadsheet and you don't have to align things to the left spine, and their are grid langs that don't do that).

The colors et al are called "secondary notations" and again Tree Notation can't be beat. Adding secondary notations is simple. Here's an example: https://www.youtube.com/watch?v=vn2aJA5ANUc

Re: The Pretty JSON Revolution

#143

Earlier quoted context omitted.

jq is a nice tool. oj is similar in many ways but different in others. jq has it's own proprietary query language while oj uses JSON path. The output options are also different with some overlap. Maybe jq will get a pretty output option after reading the article. :-)

I found JSON path to be so, so weak and limiting. Missing powerful axis traversals like xpath has, and also has very confusing semantics (the filter condition also changes the output???). I hoped to find jq as a gem/module/library but I was disappointed. After days of searching and trying different things, I honestly could not find any powerful library or API for traversing and searching JSON.

JMESPath (https://jmespath.org/) is closer to XPath, with the support for the axis traversal, filtering expressions and embeddable libraries in most mainstream programming languages. It also comes with jq-styled processing pipelines; the syntax is the same that AWS use to query AWS resources.

Re: The Pretty JSON Revolution

#146
post #142
post #135

Earlier quoted context omitted.

The Tree Notation is like the opposite of pretty notation though, no? The whole idea of pretty notation is automatically inserting non-significant whitespace to make it look nice. Step 2, "one line per node", inserts spaces and newlines. Step 4, "human style" strategically removes some of those so the lines look nice -- the 2nd level dict has lots of content, so it was split across multiple lines... while the 3rd lev…

The OP is sort of all over the place (their favorite "Pretty JSON" is not actually JSON at all, but SEN, which is definitely not JSON, which has a very discrete specification). So what they are really talking about is just pretty code. Their favorite examples utilize alignment (tree notation does that better—every tree doc is ismorphic to a spreadsheet and you don't have to align things to the left spine, and their a…

I think you missed the point here -- the great thing about author's "oj" here is that it takes existing document, with any format, and makes it look nice, in a fully automated way and without changing semantics.

(I am talking about "Human Style with Colors" here -- this is the cool part, and I don't really expect SEN to take off except to display things on the terminal)

That tabular-like alignment was generated automatically -- I can take any existing JSON data source and the program will automatically make it look nice while not requiring any changes in the consumers or producers of the data.

Compare to Tree Notation, for example this code: https://jtree.treenotation.org/designer/#standard%20iris has this block with has a clear structure:

    sepalLengthCell
     extends floatCell
    sepalWidthCell
     extends floatCell
    petalLengthCell
     extends floatCell
    petalWidthCell
     extends floatCell
    speciesCell
     enum virginica versicolor setosa
     highlightScope constant.language
This looks pretty ugly to me. There is clearly the table-like structure, but it is hard to see, because each line is split in 2. If this were JSON/SEN, I could make it look nicer:

    sepalLengthCell: { extends: floatCell }
    sepalWidthCell: { extends: floatCell }
    petalLengthCell: { extends: floatCell }
    petalWidthCell: { extends: floatCell }
    speciesCell: { 
        enum: [virginica, versicolor, setosa]
        highlightScope: constant.language
    }
See how it's all aligned now and how structure comes out? And all at zero effort from my part, it was all computer generated? But with Tree Notation, the above is invalid -- it has different meaning, so the compiler won't accept it. You have to use much uglier vertical method, with all the newlines.

And Pretty JSON can also adapt to display width. Someone with large fonts or small display can request 80 characters wide output, and "speciesCell" will be wrapped. Someone with huge display can request output 250 characters wide, and "speciesCell" will be column-aligned with others. Another thing which is pretty impossible in Table Notation without a lot of work.

Re: The Pretty JSON Revolution

#147
post #146
post #142

Earlier quoted context omitted.

The OP is sort of all over the place (their favorite "Pretty JSON" is not actually JSON at all, but SEN, which is definitely not JSON, which has a very discrete specification). So what they are really talking about is just pretty code. Their favorite examples utilize alignment (tree notation does that better—every tree doc is ismorphic to a spreadsheet and you don't have to align things to the left spine, and their a…

I think you missed the point here -- the great thing about author's "oj" here is that it takes existing document, with any format, and makes it look nice, in a fully automated way and without changing semantics. (I am talking about "Human Style with Colors" here -- this is the cool part, and I don't really expect SEN to take off except to display things on the terminal) That tabular-like alignment was generated autom…

> "oj" here is that it takes existing document, with any format

No. It takes JSON only. Which is one format out of 10,000 (though a popular one).

> There is clearly the table-like structure

It is a directed acyclic graph structure.

I won't disagree that perhaps in certain older tools oj may be better in certain situations. But Tree Notation (or more generally 2D/3D languages where positioning is the only thing used for syntax) are the future. The key thing to keep in mind is that without the colors in the last 2 examples OJ is not very useful or pretty. So to make oj nice you need to start adding parsers which are necessary for secondary notations. Then once you start adding secondary notations, 2D/3D langs make that orders of magnitude easier.

Re: The Pretty JSON Revolution

#148

I recall seeing something that claimed all JSON is syntactically valid JavaScript. If that's correct, shouldn't it be possible to use JS code formatting engines to intelligently format JSON?

Basically yes, though `{` and `}` also start and end expression blocks in JavaScript. So the JS formatter needs to be aware that it is working with a JSON object and not a complete expression.

Valid JSON:

  {
    "key1": "hello",
    "key2": "world"
  }
You could "trick" a JS formatter to format it by wrapping with a fake function, etc. Some minimum valid JS:

  json({
    key1: "hello",
    key2: "world",
  });
MongoDB has some JS libraries that use similar tricks to use JS parsers for their shell query format (which is similar to JSON). For example, around line 597: https://unpkg.com/browse/ejson-shell-parser@1.1.1/dist/ejson...

Re: The Pretty JSON Revolution

#149
post #90

Earlier quoted context omitted.

Ouch! This is borderline unreadable to me. Even more so when there's a value of length, say, 50 for the one of color keys.

What on earth is difficult to read about aligned data? More importantly, what’s more readable to you?

Ginormous distances between values and keys. It's enough to have just 2-3 long values in 2-3 different rows and the amount of whitespace becomes huge, much larger than the amount of data.

Re: The Pretty JSON Revolution

#150
post #80

Earlier quoted context omitted.

Well, falling back to the pragmatist position: a lot of JSON tooling assumes the order isn't relevant semantically. Not taking that position will cause you a lot of headaches.

...and a lot of other tooling assumes the order is relevant. Quite a lot of application logic in the real world, too. Which is why browsers preserve iteration order. JSON is a serialization format. Its components inherently have a serial order. You can't change this any more than you can legislate the value of pi to be 3.

Sure, but we were talking about being a consumer. In general, I would argue Postel's law: be careful with what you send, be liberal with what you accept.

Don't mess with the order yourself, but don't assume other tooling will respect it.

Post reply on HN