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.

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

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.

> "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.

You keep saying that "Tree Languages are the future" but I don't see any impressive examples of it. Instead, when I look at the examples, I see a rather clunky notation.

Is that iris grammar document in designer a good example? Because it does not really show why is it better than something like SEN or JSON. The text alignment is awkward, and it does not fit well on the screen. The colors are there, but I am not convinced that having keywords be a different colors outweights the ugly formatting. And I am not sure what "secondary notations" are, but I am guessing they are not present in the document?

The idea of the schemas are good. The world could use more editors with context-aware syntax highlighting and auto-completion. However, the data model you have chosen ("TreeNode=tuple(string, list[TreeNode]") doesn't map well to any programming language. And the text serialization you have chosen -- having a single canonical representation that is using whitespace as the only syntax element -- un-nesseary restricts the data that can be represented.

I think switching to a more conventional data model and text serialization will significantly increase uptake of your project, as well as make it more aesthetically pleasant. Because I seriously doubt anyone can call your existing grammar programs "nice looking".

First just want to say thanks for continuing to take the time to provide feedback. Often I'm blunt but that's just for sake of time and very appreciative of the time you have been taken to reflect on this.

    You keep saying that "Tree Languages are the future"
    but I don't see any impressive examples of it.

Binary notation as an idea was worked through for ~250 years before we had very impressive examples of it in computers, so I'm pretty happy with the examples so far given that I'm ~10 years in, and ~4 years since publication. So just at a high level the short term game common in the rest of tech isn't something I'm interested in playing.

Beyond what's out there, I've seen the results from thousands of experiments in everything from assemblies to compiler compilers to declarative data notations, and from software to hardware and everything in between, so the amount of data I have dwarfs what everyone else has seen. While I totally get that it's not raining buckets now, and in fact people feel barely a drizzle, I have quite a dataset that there are big clouds on the horizon.

    Is that iris grammar document in designer a good example?

It's mildly neat. Here's how we used an early version of that a couple of years ago to publish synthesized data for a GWAS EOPEC study (https://github.com/breckuh/eopegwas/blob/master/mockData/cli...). Tree Notation will become the standard way to describe data schemas and make synthesis a breeze.

    outweights the ugly formatting

The formatting can be described as this: minimal. In fact, the most minimal. If you think minimal is ugly, than we probably won't come to an agreement. Keep in mind though that you can write code to project Tree programs in whatever way you want. I won't disagree with the statement "Tree Notation doesn't work as well with my existing tools as other langs", but if you go back to stuff from 2017 and look at the trajectory, you'll see that Tree notation tooling has improved remarkably and in a couple more years you'll see stuff that just isn't possible with 1-D langs.

    doesn't map well to any programming language

Do you know Lisp? Tree Notation maps to S-Expressions without parens.

    un-nesseary restricts the data that can be represented.

From the paper (2017): "Prediction 1: no structure will be found that cannot serialize to TN."

    your existing grammar programs "nice looking".

To each their own. I think in the long run simplicity lasts. Also, the bigger idea isn't Tree Notation, but the idea of 2-D and 3-D languages https://longbets.org/793/

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"

Lots of code examples here: https://jtree.treenotation.org/designer/

And the source for that homepage is here: https://github.com/treenotation/treenotation.org

Always open to PR!

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.