5 ms·

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

by breck 6y ago

stevenpetryk 6y ago
This site uses only images to show the code but doesn't provide any text alternative for the image. Every image just has a `title` attribute of "Code you could hold in your hand"
- breck 6y ago
  Lots of code examples here: https://jtree.treenotation.org/designer/ https://jtree.treenotation.org/designer/ And the source for that homepage is here: https://github.com/treenotation/treenotation.org https://github.com/treenotation/treenotation.org Always open to PR!
adwn 6y ago
a) That's not relevant, b) it's not nearly as new, interesting, or revolutionary as you think it is, and c) please stop spamming links to your website in every second thread here.
- breck 6y ago
  https://giphy.com/gifs/smile-clap-laff-3oEjHI8WJv4x6UPDB6 https://giphy.com/gifs/smile-clap-laff-3oEjHI8WJv4x6UPDB6
theamk 6y ago
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 level dict has fewer data, so it all fits on one line. As opposed to this, Tree Notation is all about single canonical representation. So whitespace is significant, and you can never add or remove it to make output look nicer. You do whatever your schema tells you, and I hope you like many short lines.
- breck 6y ago
  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 https://www.youtube.com/watch?v=vn2aJA5ANUc
  - theamk 6y ago
    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 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.

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

by breck 6y ago

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

stevenpetryk 6y ago

This site uses only images to show the code but doesn't provide any text alternative for the image. Every image just has a `title` attribute of "Code you could hold in your hand"

breck 6y ago
Lots of code examples here: https://jtree.treenotation.org/designer/ https://jtree.treenotation.org/designer/ And the source for that homepage is here: https://github.com/treenotation/treenotation.org https://github.com/treenotation/treenotation.org Always open to PR!

adwn 6y ago

a) That's not relevant, b) it's not nearly as new, interesting, or revolutionary as you think it is, and c) please stop spamming links to your website in every second thread here.

breck 6y ago
https://giphy.com/gifs/smile-clap-laff-3oEjHI8WJv4x6UPDB6 https://giphy.com/gifs/smile-clap-laff-3oEjHI8WJv4x6UPDB6

theamk 6y ago

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 level dict has fewer data, so it all fits on one line. As opposed to this, Tree Notation is all about single canonical representation. So whitespace is significant, and you can never add or remove it to make output look nicer. You do whatever your schema tells you, and I hope you like many short lines.

breck 6y ago
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 https://www.youtube.com/watch?v=vn2aJA5ANUc
- theamk 6y ago
  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 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.