It's syntax error free but syntax includes whitespace, does that mean you just hid all syntax errors inside the semantics errors bucket?
In what exact ways is tree notation more base than all the other notations that make it such a strong choice?
It's mentioned it can't map 1:1 to JSON/XML, if it's just words and nodes at an offset why not?
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.
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.
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 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"?
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.
Wat. No, they're not. Counter-example: triangles. Triangles are not trees.
I did, however, notice that you've been spamming all kinds of threads with posts along the lines of "Apropos topic X, Tree Notation will totally revolutionize X. Follow tree-notation-URL to stay up-to-date with Tree Notation, once [if] we ever find a way to explain what makes Tree Notation so different from other notations!"
(where X is a random topic which is mostly or completely unrelated to Tree Notation)
It's quite annoying.
> where X is a random topic which is mostly or completely unrelated to Tree Notation)
What is binary notation related to? Is it related to medicine? It is related to automobiles? Is it related to deep space? Is it related to food? Is it related to government? Try to do any of those things without binary notation. This is a big idea. A very infrequent big idea.
So what are your definitions of tree and triangle?
Mathematics is not a rigorous language, so I'll put the crux of my argument in Tree Notation, which is a rigorous language:
betterGraphTheoryLanguage
nodeCell
cycleNode
triangleNode
extends cycleNode
cells nodeCell nodeCell nodeCelltypo fix: changed Trees to Tree Notation.
Uh huh. Great start...
> I'll put the crux of my argument in Trees, which is a rigorous language
Interesting how you're overloading the word "tree" in this context. You're presenting a definition in the format of a tree. And concluding that the resulting object is itself a tree. It's like saying that swords are made of wood, and proving it by carving the definition of a sword into a piece of wood. This is quackery.
Graphs, and trees, have perfectly rigorous definitions. They've been defined in a plurality of rigorous languages. Your "definition" doesn't even mention edges, unless they're implied by "cycleNode" somehow; in either case it appears that your "better" graph theory only contains a single graph of any given order. Graph theorists expect a few more than that.
Let me define a "rigorous" language.
A rigorous langauge is one which can be defined completely in a single document starting with 0 and 1 and working it's way all the way up to whatever it is you want to prove.
> Graphs, and trees, have perfectly rigorous definitions. They've been defined in a plurality of rigorous languages.
If you can provide a link to a single page that starts with 0 and 1 and builds all the way up to defining "graphs and trees" and how a "triangle is not a tree", then I will agree with you.
> Interesting how you're overloading the word "tree" in this context.
Sorry, that was a typo, I meant to write Tree Notation. I'll fix.
Is there a document like this for your tree notation? Not trying to criticize; I'm legitimately interested to see how this would be done.
I wish. We have a lot of ongoing threads about it. Someone has one somewhere for logic gates, IIRC.
Here's a snippet from 1 from a conversation the other day on how to build up to an if statement.
0
1
2 10
...
i 01101001
...
f 01100110
...
if 1
2
The idea is we'd like to be able to compare 2 systems objectively and decide which is the simpler one.
Here's a rough paper from 2017 (before I had any experience in academia): https://github.com/treenotation/jtree/blob/master/papers/pap...
From the examples it seems like a newline deliminated text format that uses spaces for indentation with indentation levels representing nested structure. Which seems fine enough but I feel like I'm missing some sort of philosophically profound implication of this format or something.
Change the word "Tree Notation" to "binary Notation". What we discovered is that there is a remarkably simple notation that is all you need for representing abstractions and higher level languages.
Just as Leibniz in the 1600's discovered that all you need is 0 and 1 to represent all information, we discovered that all you need is trees to represent all structures(and tree notation -- the most minimal way to encode trees), that has profound implications, just like binary.
Think about all the things you use that depend on binary. All of the systems that depend on our modern will programming languages, Tree Notation will make all of those systems better in the decades ahead.
People will say this is just "S-Expressions". Exactly! Except S-Expressions done correctly! When you try to reduce S-Expressions to perfection, you get Tree Notation. If you know S-Expressions and you still don't get that, this might help: https://medium.com/@breckyunits/removing-the-2s-from-trinary...
You should read "Zen and the art of motorcycle maintenance", it a autobiography of a man who develops a meta-physical system existing of the holy trinity of a thing, the representation of a thing and the essence this representation is missing. Don't read it for the theory but the slow decent into madness.
No I mean "we". This is a huge collaborative effort. We wouldn't be getting anywhere if not for the help of many dozens (more like hundreds, at this point) people helping out.
> "Zen and the art of motorcycle maintenance"
I have that book, I can't remember reading it, however. Thanks for the rec. I'll give it another look.
> Don't read it for the theory but the slow decent into madness.
The reason why you see my name everywhere and no one else's is merely because of comments like this. I have very thick skin and can take it, but I don't want to subject my friends and collaborators to this kind of gaslighting. We are almost at the point where the evidence is overwhelming that this theory is correct, and we have peer-reviewed papers in the works (with dozens of collaborators with fancy edu positions whose full names will be on the paper), and then it's game over. In the meantime you can either look at the increasing piles of extraordinary evidence (for example, I made a language today called Dumbdown in less than an hour http://treenotation.org/designer/#standard%20dumbdown that I would not be surprised if a variant evovles to be bigger than markdown) and think about things for yourself, or jump to a (wrong) conclusion simply because this is a low probability/black swan/outlier event.
Black swans are rare. But they do happen.
So to me it's not a matter of subjective taste but rather pragmatism. S-expressions are just easier to edit.
But I also think the world without parens will be a much better place, once we get there with the tooling and ecosystem.
I don't know how long that will take. 2020 I hope?
My dude, maybe you're on to something clever, maybe you're just chasing your own tail. But until you write down clearly exactly what it is that you're on about, nobody can tell. And then you're just annoying us.
Focus on a single document somewhere that explains enough to make just a few people go "Aha, this can be used for X! I'll contribute!"
Now you have three half-baked "papers" on various stuff, a "data science platform" that I can't figure out how works, and lots of vague fluffy ideas.
> Focus on a single document somewhere that explains enough to make just a few people go "Aha, this can be used for X! I'll contribute!"
I'm working with well over 50 different people in many countries at this point helping them with their tree languages and projects. So even if the majority of people don't yet understand what the heck this is all about, enough do that we're starting to make faster progress.
What you are seeing is a lot of data points. 2 years I made a logical argument, but that didn't go very far. Extraordinary claims require extraordinary evidence. Get ready for a deluge of extraordinary evidence.
Tree Notation is free and open and there is no signup form. Just take it and do what you want with it. Play with it, examine it, see how it is built, see how it has evolved, try to find flaws, try to utilize its strengths, monetize it, share it, troll it, whatever you want.
There's no secrecy with Tree Notation. It's all out there.