undefined | Better HN

0 pointstheamk5y ago0 comments

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

0 comments

1 comments · 1 top-level

breck5y ago

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/

j / k navigate · click thread line to collapse