Comment by breck | Hacker News Reader

Comment by breck | Hacker News Reader

Parent Full thread

> there is very little explanation of what the heck Tree Notation

The docs are weak, but resources are limited. Ideally people will start their own sites/blogs/etc where they try to explain Tree Notation in their own words. All of the questions you have below are answered in many places (people have had hundreds+ of questions, so I do my best to answer them but I'm not doing a great job at organizing these -- the Faq, gihtub, papers, and subreddits are helping, but ideally other people will start to create content).

> It's syntax error free but syntax includes whitespace, does that mean you just hid all syntax errors inside the semantics errors bucket?

Just like there are no errors in binary, there are no errors in tree notation. Tools can operate on binary without understanding the semantics. Tools can operate on tree notation without understanding the semantics. This is very powerful. If you have experience writing tools that parse/edit/generate code, it should click. If you don't, try building some stuff that does using some existing techniques and tools from parsing, grammar, and compiler theory and then give Tree Notation a shot. There still are errors at the Tree Language level, but they become much easier to handle and fix.

> In what exact ways is tree notation more base than all the other notations that make it such a strong choice?

All of the other notations listed have both syntax errors and semantic errors. Tree notation eliminates the entire category of syntax errors.

> It's mentioned it can't map 1:1 to JSON/XML, if it's just words and nodes at an offset why not?

Subtle details, but certain properties of those languages (like XML's dual attributes/tags axes) or higher level constructs (Tree Notation does not have a concept of "number" you need a higher level Tree Language for that) prevents the direct mapping unless you use a higher level Tree Language.

> Tree notation could be the greatest thing since sliced bread but the pages on the website do nothing to help me understand what it actually is just that it's great.

I agree. Help wanted! Anyone is welcome to build their own sites about Tree Notation and/or contribute pull requests to the docs and repos.

> Just like there are no errors in binary, there are no errors in tree notation. Tools can operate on binary without understanding the semantics.

The scope of tools is pretty limited though: compression, encryption, ecc/encoding.

> Tools can operate on tree notation without understanding the semantics. This is very powerful.

GIGO still applies. So you move your errors downstream, as mentioned. The space where this is a win also seems pretty limited.

> The docs are weak

The docs are more than weak, for something that's supposed to take over the world in 2 years I can't even click half the links in the FAQ?

> Just like there are no errors in binary, there are no errors in tree notation.

You can make any format "no errors" with little effort, the problem is not creating garbage data in the process.

> Tools can operate on binary without understanding the semantics. Tools can operate on tree notation without understanding the semantics. This is very powerful.

And there are infinitely many representations which can take this form. The problem is all such representations are no different than each other. I.e. tree notation can't represent anything binary can't. To actually do anything new you need to understand the syntax so if the main selling point is "are syntax accepts anything" well so does a million others before and after. The question isn't "how can generic encoding work" it's "what does Tree Notations syntax do that others don't already".

> All of the other notations listed have both syntax errors and semantic errors. Tree notation eliminates the entire category of syntax errors.

But they aren't eliminated at all they are just hidden to produce garbage later on instead. In S-expressions if I randomly drop a parenthesis I have mismatched syntax. In Tree Notation if I randomly drop a newline I have some completely different piece of data that validly represents garbage. The issue isn't eliminated just because it parses and this isn't the first format that can hold arbitrary data!

.

In the end though what is this beyond yet another form of S-expression? Is there something it does that a simple replacement regex would generate an invalid S-expression? If not why blow smoke up everyone's ass instead of just saying "Tree Notation is a S-expression format that uses whitespace instead of parenthesis"?

> The docs are more than weak, for something that's supposed to take over the world in 2 years I can't even click half the links in the FAQ?

On my goodness. Thank you. Fixed. I have a script that checks for broken links "npx linkinator -r https://treenotation.org" but I must have screwed something up because those were not getting detected. (Nit: 10 years! not 2 ;) )

> You can make any format "no errors" with little effort, the problem is not creating garbage data in the process.

This is a very valid point. But Tree Notation does give you a lot of meaning -- lines/words/scopes -- without knowing the semantics of the Tree Language. But you do have a good argument here that if people don't come to a consensus on even these things, then Tree Notation could just be garbage. There will need to develop a common language for the universal tree notation semantics.

> And there are infinitely many representations which can take this form.

Good point.

> The question isn't "how can generic encoding work" it's "what does Tree Notations syntax do that others don't already".

Tree Notation is the simplest method we can come up with to do all the things are existing syntaxes and languages can do. By simplest, we mean "tree notation will always have fewer or equal pieces in terms of absolute complexity than a different notation for any given task". And our bet is that simplicity of atomic ingredients triumphs in the long run because less costs less.

But the proof is in the pudding. Tree Notation won't really start taking off (if ever) until there is better tooling and some "killer app" new tree languages.

> But they aren't eliminated at all they are just hidden to produce garbage later on instead.

Clinicians are now using Tree Notation to write their medical records on pen and paper (peer reviewed paper coming soon). There's no such thing as syntax errors. Their "code" looks just like S-expressions, with prettified formatting, except without paranetheses. They can have semantic errors using either one (for instance, spelling "dose as does"). But they cannot have syntax errors with Tree Notation. Imagine instead we were instructing them to use S-Expressions--suddenly their notebooks would be filled with syntax errors for missing paranetheses. They would have 0 benefit and all downside by adding parens.

> If not why blow smoke up everyone's ass instead of just saying "Tree Notation is a S-expression format that uses whitespace instead of parenthesis"?

I'm putting a small fortune and an immense amount of effort into this (and giving everything away), because I believe it will eliminate drastic amounts of unnecessary complexity in so many domains all throughout the world, and will indeed, amongst other things, help us cure cancer, which is certainly near and dear to my heart and I'm sure to so many other people on here. I want to make the biggest and boldest statements I can here, so I can get harsh and sharp critical feedback like yours, that is very helpful and can save us time by pointing out flaws (both in theory and practice like the broken links). If this were something for Lispers, I wouldn't care so much (I love lisp, but it would be an incremental improvement). This is for all the people of the world. We are going to simplify and make better code in all domains. It's a mammoth effort that's going to take billions and thousands of smart people. This is just the beginning.

Reply on news.ycombinator.com