This is pretty cool. I just don’t understand your insistence that it’s all about the tree notation. I’d love to see a proper description of the grammar. It seems to have echoes of OMeta.
Tree Notation is helpful for lexing. But your demos inevitably have a lot more than lexing. Either you need to treat them as first class research objectives. Or you need to make it easy to tease apart all the moving parts, by say showing how the same language is implemented with the same grammar language in tree notation vs a more conventional lexer.
I just don’t understand your insistence that it’s all about the tree notation.
I know I’ve done a lousy job so far at explaining what I see. I gave a talk 2 years ago about thinking about source code in 2 and 3 dimensions. You can definitely do this type of language in traditional manners with parsers that have colons and semicolons and brackets etc, but my insistence is none of that is necessary. Our mission is to rid the world of unnecessary complexity (while leaving art untouches :) ). For reference, Dumbdown took me approximately 50 minutes from idea to shipping an MVP with autocomplete, syntax highlighting, parsing, type checking, compiling, and unit tests. And the code is relatively timeless. I know I am not doing a good job at explaining why Tree Notation makes this possible, but I hope empirically the data points will start adding up, and maybe people smarter than I am can explain it better.
I’d love to see a proper description of the grammar.
The Dumbdown grammar is 84 lines long. It it written in a Tree Language called Grammar. Grammar is written in itself and is 300 lines long: https://treenotation.org/designer/#standard%20grammar (though at the moment the compiler for Grammar is still written in TypeScript).
The notation for grammars seems quite barbaric.
I’ve gotten super fast with it but there’s lots to be improved. The “Infer Grammar” button on the designer app can be helpful. But really I should record some demo videos or something for now, until it’s good enough that it is self explanatory.
But your demos inevitably have a lot more than lexing. Either you need to treat them as first class research objectives. Or you need to make it easy to tease apart all the moving parts, by say showing how the same language is implemented with the same grammar language in tree notation vs a more conventional lexer.
An immense amount of work to do. The goal is to build a movement that can do these sort of things. Tree Notation now is about where the Web was in ~1989. Just at the very beginning. There are endless applications of this. We need help with all the things. Perhaps the biggest help of all would be someone better than me at organizing the helpers :).
I think you should set aside time to explain what it is, how it works, and with examples. It’s worth having an accessible description of the thing you spent years on if you’re trying to present it to others. The submission makes me think you are. So, definitely make something that lets us know what Grammar is and how it works. Then, people can start making comparisons, experimenting, etc.
I think you should set aside time to explain what it is, how it works, and with examples.
This is very good advice and feedback. I think the problem is I’m trying to do this, and now have papers, FAQs, blog posts, demo apps, source code, over a dozen sample languages, and I’m still doing a terrible job at it. Here in person at the Cancer Center coworkers are able to explain it to new people better than me. I think we just need to find someone who is great at visuals, youtubes, or whatever, to lead a better explanatory site. I could work on improving my skills in that domain (and I will keep improving), but there’s still so much work to do on the programming end that if we could find the right collaborators to lead that sort of site, that might be the more efficient approach.
Yes, Ometa, TXL, and Rascal are all ones I studied. Thank you for pointing those out. Often when someone mentions something, even though I may have studied it at one point, it’s a great signal that I should go take another look to see what things I missed. Thanks.
What would you say is the type of person that can see what you see? I’m basically just a techy Joe Schmoe but I find it easier to understand M theory than your work on Tree Notation. Do I have to have a PhD in math/cs to understand this stuff?
Do I have to have a PhD in math/cs to understand this stuff?
Well I only have a bachelors in Economics (and flunked out of college once), so I guess that would mean no.
What would you say is the type of person that can see what you see?
I just stumbled upon this notation which seemed a simple way to do things. I asked people much smarter than me for years for help and guidance and whether they thought it would be useful. No one thought it was interesting but no one could explain to me why it wasn’t. So I spent years and years trying to find flaws in it, and thinking of all the places where it could help. So I have about 7 years or so of thinking about this and researching it somewhat obsessively. I built a database of 10K+ notations and languages with 1k+ columns and there’s not a single instance found where another notation or language can do things simpler than Tree Notation (by simpler I mean with fewer parts). I built crude hardware that could operate directly on Trees (instead of our register based models of computing). I built 3-D models of programs (copying the research techniques of watson and crick). I even spent 2 months trying microdosing to figure it out.
And I’ve probably made some obvious dumb flaws but there’s something interesting here. I bet today’s version is garbage to the version that is out in 1 year.
Anyway, so what type of person does it take to see what I see? A really dumb stubborn person I guess.
The Dumbdown grammar is 84 lines long. It it written in a Tree Language called Grammar. Grammar is written in itself and is 300 lines long: https://treenotation.org/designer/#standard%20grammar (though at the moment the compiler for Grammar is still written in TypeScript).
Yes, I’ve read that paper a couple times and am familiar with VPRI. Alan Kay’s ideas have very much helped me along the way. I don’t believe I’ve talked to anyone from VPRI though (or the later YC backed lab that did similar work). Thank you for mentioning that again. I’ll give it another look.
“Well I only have a bachelors in Economics”
“So I spent years and years trying to find flaws in it, and thinking of all the places where it could help. So I have about 7 years or so of thinking about this”
You’ve put about a Ph.D.’s worth of time into this, though. It might be harder out of the blue than you realize.
You’ve put about a Ph.D.’s worth of time into this
I laughed out loud at this. I never thought of it so succinctly. You got me thinking and I did a Google search for “Can you get a PhD without going to graduate school?”. Looks like such a thing might be possible, but only in the UK where it looks like if you have some peer reviewed papers you can apply for a “phd by merit”. Not sure if that’s accurate, just what a quick Google search.
It might be harder out of the blue than you realize.
I realize it’s really hard. I’ve done thousands of experiments on Tree Notation and many more experiments that I’ve just “run in my mind” over the years. So I see what it will become. (And that’s if there isn’t some fatal flaw that I have overlooked, which I still has at least a 10% probability of happening). So I’ve envisioned all the use cases, the benefits, and how to overcome the challenges. Only now are things starting to get good enough where other people are seeing the potential.
Here at the Cancer Center I no longer explain it to people when I can help it, letting instead other people at the lab explain it who have far less experience with it than me. They do a better job at explaining it. I’m hoping we find one or more people who are good ad visuals and communicating and could build us a new website (https://www.reddit.com/r/treenotation/comments/cyjfpy/wanted_someone_to_redo_the_treenotationorg/) to explain it better. Pull requests are also welcome.
I’ve gone through your website and previous posts in the past, and I legitimately had a false memory in my mind (until you corrected it) that your website said you were working on your PhD. Very strange.
Hmmm. I have toyed with pursuing it, but the way the system is setup in the U.S. doesn’t really make sense. Seems more like indentured servitude than science to me :)
This is kind of out of left field, but I’m very much against what some wise people call “Intellectual Slavery” laws of copyrights and patents, so it would be hard for me to stomach going along with a system of closed access journals, expensive textbooks, etc. And like I said, I already flunked out of school once so I just don’t think it’s a good fit :).
My wife has a PhD though and so do most of my coworkers (some of them are phd students). Do you have one? Would you recommend it? I’m kind of curious if there’s a way to do it that would make sense, perhaps outside of the US.
I’m nowhere near having a PhD so unfortunately I can’t give any advice from my own experience. From what I’ve seen though, a PhD is only really good for academia/research (even in CS) so I feel like you probably wouldn’t benefit from it, all things considered. You would probably get better advice from your wife and coworkers though :p
Below is a visualization that you have to look at with a grain of salt because it’s not quite accurate, but this is the type of thing I see when I look at Tree Languages. Basically, programs are like spreadsheets, 2D grids of cells. The location of a word is meaningful and grounded in geometry. The parsed version has the same shape.
You seem open to some feedback, so, here’s some of mine, as someone who’s looked a couple of times at Tree Notation and still hasn’t quite “got it”. I’ve just spent the last 20 minutes looking again at various parts of the site.
(Before I go any further, please be assured this is meant with the best of intentions, and no malice. I feel like there’s something here, and a lot of work has gone into it but somehow I’m not getting it - and I’m not sure what steps I would need to take to get there).
The “What is Tree Notation?” on the front page doesn’t explain what it is, except for the hint “Tree Notation is an error-free base notation like binary”. But I don’t really know what that means.
“Tree Notation […] is grounded in 3-dimensional geometry” (again, from the front page) doesn’t mean anything to me at this point. Honestly, it made me think of Time Cube. I’m sure there’s something there, but I feel intimidated by the idea that I need to understand something mathsy to use Tree Notation. I think I have completely misunderstood what this sentence means, but I also have no idea what it means.
The example with package.json looks like an alternative syntax for JSON. I think the point is that you can write a syntax for JSON itself in Tree Notation? Which makes it like… JSON Schema? What’s the comparison to something I might be familiar with?
The Lisp example is basically the same. It just looks like an alternative grammar: S-Exps without the parens. It’s not obvious how or why this is useful.
On the Grammer section of the front page:
You can write new Grammar files to define new languages. By creating a grammar file you get a parser, a type checker, syntax highlighting, autocomplete, a compiler, and virtual machine for executing your new language.
You know, I’d probably lead with this. I think it’s the most concrete information on the page
In the “Who this Library is For” section, I’m unclear what “this Library” is at this point. Is it everything I need to write a language? Is it a parser for tree notation?
The checklist is halfway to being a tutorial. It would be good if it explained the “why” as well as the “what” (and be careful about snipping previously-seen code out of the examples in the tutorial. Much better, IMO, to show all code and note what has changed from the previous block than to elide the code and expect people to remember what it was - don’t make me think ;) )
For reference, Dumbdown took me approximately 50 minutes from idea to shipping an MVP with autocomplete, syntax highlighting, parsing, type checking, compiling, and unit tests.
A walkthrough tutorial for putting this together would probably be super helpful and cool.
Here at the Cancer Center I no longer explain it to people when I can help it, letting instead other people at the lab explain it who have far less experience with it than me. They do a better job at explaining it.
Maybe get those written down? Or see if there are common ways it’s being communicated by these people that aren’t currently on the site.
as someone who’s looked a couple of times at Tree Notation and still hasn’t quite “got it”. I’ve just spent the last 20 minutes looking again at various parts of the site.
Thank you very much for taking the time. Truly grateful. This is such good data that the current docs are just not doing a good job. I’m thinking perhaps we need to take a much more “show vs tell” approach, with videos, screenshots, animated gifs, visualizations, demos up front, etc, and move the text and FAQ.
Before I go any further, please be assured this is meant with the best of intentions, and no malice.
You are too nice!
on the front page doesn’t explain what it is,
Good point. The more I think about it the more I think the front page should all be show versus tell.
Tree Notation […] is grounded in 3-dimensional geometry” (again, from the front page) doesn’t mean anything to me at this point.
This just means that programs have a 3-D representation. Think of them like molecules. Here’s a video of a talk I gave 2 years ago (https://www.youtube.com/watch?v=ldVtDlbOUMA) that might clarify that more. It was at JSConf 2017 in SF, I’m looking for the actual video and not just my screen recording, but can’t find it. With traditional languages the first step in parsing is to generally strip whitespace and turn the code into a 1D sequence. Your code is not mapped into the 3D world. With Tree Notation it is, and there’s a location of each word/line, and changing that changes the meaning of the program. It’s like a design constraint. Tree Notation programs in a sense need to obey the laws of physics (I know that’s an inaccurate cliche, but might hint at what I’m getting at?).
it made me think of Time Cube
I’m not familiar with that one, but I totally understand the feedback that this is “A New Kind of Science” type of thing. That’s why I spend most of my time on code, tooling, data gathering, products, user tests and demos and putting the theory into practice, and comparatively little of my time on papers and theoretical work. I’ve tried to see where others who have stumbled upon something similarly simple and perhaps profound have erred. A New Kind of Science has been very influential to me in particular as an experiment of what would it look like to go all in on the theoretical aspect, and my takeaway from that is that it’s a brilliant 50-100 page book, but then it just goes way to far out on a limb and so the priority when dealing with a new library should be to slowly and incrementally build up the tooling to bring practical benefits from the work out early, while putting the theoretical implications as a lower priority. Not descending into madness, while not staying totally practical, while also not listening to people who are trying to disparage the work by saying you are descending into madness, it’s a tricky balance to maintain but I’ve got some good strategies built up to walk that line :)
The example with package.json looks like an alternative syntax for JSON. I think the point is that you can write a syntax for JSON itself in Tree Notation? Which makes it like… JSON Schema? What’s the comparison to something I might be familiar with?
The Grammar Tree Language is sort of like JSON Schema. I just updated that example a bit with more information. Tree Notation is very low level (think binary or ascii). The Tree Languages can do anything (so you can have a Tree Language that maps to JSON like the Dug demo language, or you can make a Tree Language for building languages like Grammar, or you can make a general purpose Tree Programming language, etc). The idea is none of those things require parens or brackets or colons etc. Simple positioning in 3D geometry is the only thing we need to do all of the things that we traditionally use syntax for. Positioning gives you abstraction, scope, trees, etc. The building blocks for everything else.
The Lisp example is basically the same. It just looks like an alternative grammar: S-Exps without the parens. It’s not obvious how or why this is useful.
If you look at any one example you can say they all are only incremental improvements. It’s all about the network effects. I did not write syntax highlighting for my lisp like Tree Language. I wrote it for my HTML Tree Language. But It works for both. Etc. If you master the basics of Tree Notation syntax (maybe there’s like 5 rules? I’m not sure how many but it’s less than 10 for sure), you understand the syntax for now dozens of languages (and hopefully in the future, thousands). The semantics you need to learn from that domain, but hopefully we eliminate one large category of mistakes and confusion.
You know, I’d probably lead with this. I think it’s the most concrete information on the page
Good idea. Thanks! Will probably do that in the new version.
In the “Who this Library is For” section, I’m unclear what “this Library” is at this point. Is it everything I need to write a language? Is it a parser for tree notation?
This is a common point of confusion. We should reorganize it so there’s the Tree Notation landing page, and then there’s the JTree Landing page (the tree notation library for TypeScript/Javascript). In the new redesign, we’ll remove the Jtree specific stuff and instead add links to all the different implementations, similar to json.org.
The checklist is halfway to being a tutorial. It would be good if it explained the “why” as well as the “what” (and be careful about snipping previously-seen code out of the examples in the tutorial. Much better, IMO, to show all code and note what has changed from the previous block than to elide the code and expect people to remember what it was - don’t make me think ;) )
Good feedback! Thanks. Someone is volunteering to do a new one. Hopefully he’ll post that soon.
A walkthrough tutorial for putting this together would probably be super helpful and cool.
Noted. Will add..
Maybe get those written down? Or see if there are common ways it’s being communicated by these people that aren’t currently on the site.
Great idea. I just sent an email to the lab folks. Will add.
Yeah, it’s painful in this regard. Yesterday’s designer launch addressed a number of the most common issues, but still the list of things to do and user requests is a mile long. The in person community here is very helpful, but hoping we’ll be able to get a community going of remote contributors in the months ahead.
How quickly you can use it is not a great signal
Agreed. It’s what I have though, until the tooling gets better. I guess the promising signal though is that this sort of thing would have taken me 10 hours or more 6 months ago (speaking in rough estimates), so the trend is in the right direction.
There’s a thing at work we’re currently representing rather clumsily with JSON that I’ve been wanting to find a better encoding for. Defining a tree language for it, and a back-and-forth converter between tree notation and the current JSON might be a cheap experiment to see what it’s all about.
If tree notation is as useful as you make it sound, that could be a huge productivity boost. It sounds like it could make it easier for people to edit these structures by hand, to write more advanced features for the visual editor, create automatic transformations of common patterns, and so on.
I apologize in advance for the difficulty as the current state of things is early, but appreciate any help toward making things better for the future community!
Is there any way to import/source files into another,
In dumbdown or the grammar language?
Grammar files: We are exploring adding imports/exports via the filesystem, or even via urls or some type of registry, but nothing at the moment. The current solution is just to concat the two files together (the last root node becomes the root node for the new combined grammar), generally via a build step. As far as I know this is the simplest grammar concatenation language ever devised (but I could be wrong). Here’s an example that adds a comment node type (https://github.com/treenotation/jtree/blob/master/langs/jibjab/jibjab.gram) to the jibberish language and calls the new resulting language “jibjab”.
For dumbdown no, but I’d be interested in seeing if people tried that. I could see it could be helpful for something like a book language. But I wonder if the build/concat approach would be best for that situation as well.
references the same tree node at multiple places?
In Grammar you can reference nodeType definitions and/or cellType definitions in multiple places. Not sure specifically if that’s what you are talking about, or something else? At the Tree Notation level there is no concept of a symlink. That is something that needs to be defined at the Tree Language level. Though some people have suggested adding some type of reference syntax to the tree notation level (something like http://ogdl.org/), I haven’t yet found a way that is simple and antifragile. Perhaps the best way to do it is just to combine the number in the cell (treating a word as just a number) coupled with the location of the cellType definition in a grammar to triangulate a reference.
Yes, I was thinking of “symlink” nodes, much like leo-editor has. I was thinking something like named nodes, where the same place in a tree can (de)reference another node component, and changes to that node are reflected in all refs - much like if you imported it into a position in a tree.
“Outline nodes may appear in more than one place, allowing multiple organizations of data within a single outline.”
I’m not sure I understand this. Is this just projectional editing? For example, on https://ohayo.computer you can edit the source by hand on the left or edit things with your mouse on the right.
Or is it just symlinks/imports? I have a lot of languages that are simply the result of concat’ing “gram” files into “grammars”, and if you change one “gram” file that is imported by multiple languages you update all those languages, though I currently implement that as a build step and not in the language itself.
Leo looks very interesting. It seems familiar, but I can’t recall seeing it or find any notes on it, at the moment, so could be new to me. Thanks for sharing.
This is pretty cool. I just don’t understand your insistence that it’s all about the tree notation. I’d love to see a proper description of the grammar. It seems to have echoes of OMeta.
I just noticed the link to https://github.com/treenotation/jtree/blob/master/languageChecklist.md. The notation for grammars seems quite barbaric. But maybe I just don’t understand. A more elaborate write-up than a checklist may help.
Tree Notation is helpful for lexing. But your demos inevitably have a lot more than lexing. Either you need to treat them as first class research objectives. Or you need to make it easy to tease apart all the moving parts, by say showing how the same language is implemented with the same grammar language in tree notation vs a more conventional lexer.
I know I’ve done a lousy job so far at explaining what I see. I gave a talk 2 years ago about thinking about source code in 2 and 3 dimensions. You can definitely do this type of language in traditional manners with parsers that have colons and semicolons and brackets etc, but my insistence is none of that is necessary. Our mission is to rid the world of unnecessary complexity (while leaving art untouches :) ). For reference, Dumbdown took me approximately 50 minutes from idea to shipping an MVP with autocomplete, syntax highlighting, parsing, type checking, compiling, and unit tests. And the code is relatively timeless. I know I am not doing a good job at explaining why Tree Notation makes this possible, but I hope empirically the data points will start adding up, and maybe people smarter than I am can explain it better.
The Dumbdown grammar is 84 lines long. It it written in a Tree Language called Grammar. Grammar is written in itself and is 300 lines long: https://treenotation.org/designer/#standard%20grammar (though at the moment the compiler for Grammar is still written in TypeScript).
I’ve gotten super fast with it but there’s lots to be improved. The “Infer Grammar” button on the designer app can be helpful. But really I should record some demo videos or something for now, until it’s good enough that it is self explanatory.
An immense amount of work to do. The goal is to build a movement that can do these sort of things. Tree Notation now is about where the Web was in ~1989. Just at the very beginning. There are endless applications of this. We need help with all the things. Perhaps the biggest help of all would be someone better than me at organizing the helpers :).
I think you should set aside time to explain what it is, how it works, and with examples. It’s worth having an accessible description of the thing you spent years on if you’re trying to present it to others. The submission makes me think you are. So, definitely make something that lets us know what Grammar is and how it works. Then, people can start making comparisons, experimenting, etc.
You might also find Ometa, TXL, and Rascal interesting.
This is very good advice and feedback. I think the problem is I’m trying to do this, and now have papers, FAQs, blog posts, demo apps, source code, over a dozen sample languages, and I’m still doing a terrible job at it. Here in person at the Cancer Center coworkers are able to explain it to new people better than me. I think we just need to find someone who is great at visuals, youtubes, or whatever, to lead a better explanatory site. I could work on improving my skills in that domain (and I will keep improving), but there’s still so much work to do on the programming end that if we could find the right collaborators to lead that sort of site, that might be the more efficient approach.
Yes, Ometa, TXL, and Rascal are all ones I studied. Thank you for pointing those out. Often when someone mentions something, even though I may have studied it at one point, it’s a great signal that I should go take another look to see what things I missed. Thanks.
What would you say is the type of person that can see what you see? I’m basically just a techy Joe Schmoe but I find it easier to understand M theory than your work on Tree Notation. Do I have to have a PhD in math/cs to understand this stuff?
Well I only have a bachelors in Economics (and flunked out of college once), so I guess that would mean no.
I just stumbled upon this notation which seemed a simple way to do things. I asked people much smarter than me for years for help and guidance and whether they thought it would be useful. No one thought it was interesting but no one could explain to me why it wasn’t. So I spent years and years trying to find flaws in it, and thinking of all the places where it could help. So I have about 7 years or so of thinking about this and researching it somewhat obsessively. I built a database of 10K+ notations and languages with 1k+ columns and there’s not a single instance found where another notation or language can do things simpler than Tree Notation (by simpler I mean with fewer parts). I built crude hardware that could operate directly on Trees (instead of our register based models of computing). I built 3-D models of programs (copying the research techniques of watson and crick). I even spent 2 months trying microdosing to figure it out.
And I’ve probably made some obvious dumb flaws but there’s something interesting here. I bet today’s version is garbage to the version that is out in 1 year.
Anyway, so what type of person does it take to see what I see? A really dumb stubborn person I guess.
Are you familiard with paper STEPS Toward The Reinvention of Programming and generally VPRI?
Yes, I’ve read that paper a couple times and am familiar with VPRI. Alan Kay’s ideas have very much helped me along the way. I don’t believe I’ve talked to anyone from VPRI though (or the later YC backed lab that did similar work). Thank you for mentioning that again. I’ll give it another look.
“Well I only have a bachelors in Economics” “So I spent years and years trying to find flaws in it, and thinking of all the places where it could help. So I have about 7 years or so of thinking about this”
You’ve put about a Ph.D.’s worth of time into this, though. It might be harder out of the blue than you realize.
I laughed out loud at this. I never thought of it so succinctly. You got me thinking and I did a Google search for “Can you get a PhD without going to graduate school?”. Looks like such a thing might be possible, but only in the UK where it looks like if you have some peer reviewed papers you can apply for a “phd by merit”. Not sure if that’s accurate, just what a quick Google search.
I realize it’s really hard. I’ve done thousands of experiments on Tree Notation and many more experiments that I’ve just “run in my mind” over the years. So I see what it will become. (And that’s if there isn’t some fatal flaw that I have overlooked, which I still has at least a 10% probability of happening). So I’ve envisioned all the use cases, the benefits, and how to overcome the challenges. Only now are things starting to get good enough where other people are seeing the potential.
Here at the Cancer Center I no longer explain it to people when I can help it, letting instead other people at the lab explain it who have far less experience with it than me. They do a better job at explaining it. I’m hoping we find one or more people who are good ad visuals and communicating and could build us a new website (https://www.reddit.com/r/treenotation/comments/cyjfpy/wanted_someone_to_redo_the_treenotationorg/) to explain it better. Pull requests are also welcome.
I’ve gone through your website and previous posts in the past, and I legitimately had a false memory in my mind (until you corrected it) that your website said you were working on your PhD. Very strange.
Hmmm. I have toyed with pursuing it, but the way the system is setup in the U.S. doesn’t really make sense. Seems more like indentured servitude than science to me :)
This is kind of out of left field, but I’m very much against what some wise people call “Intellectual Slavery” laws of copyrights and patents, so it would be hard for me to stomach going along with a system of closed access journals, expensive textbooks, etc. And like I said, I already flunked out of school once so I just don’t think it’s a good fit :).
My wife has a PhD though and so do most of my coworkers (some of them are phd students). Do you have one? Would you recommend it? I’m kind of curious if there’s a way to do it that would make sense, perhaps outside of the US.
I’m nowhere near having a PhD so unfortunately I can’t give any advice from my own experience. From what I’ve seen though, a PhD is only really good for academia/research (even in CS) so I feel like you probably wouldn’t benefit from it, all things considered. You would probably get better advice from your wife and coworkers though :p
Below is a visualization that you have to look at with a grain of salt because it’s not quite accurate, but this is the type of thing I see when I look at Tree Languages. Basically, programs are like spreadsheets, 2D grids of cells. The location of a word is meaningful and grounded in geometry. The parsed version has the same shape.
https://ohayo.computer?filename=untitled-2.flow&yi=~&xi=_&data=data.inline~_parser_text~_treeLanguage_flow~_treenotation.3d~_content~__title_This_is_Dumbdown._The_keyword_for_title_is_title.~__subtitle_Dumbdown_compiles_to_html.~__paragraph_Dumbdown_is_an_alternative_to_Markdown.~__~__paragraph_Blank_lines_get_turned_into_%253Cbr%253E~__~__link_https%253A%252F%252Ftreenotation.org%252F_It_is_built_on_Tree_Notation~__~__code~___alert(%2560The_keyword_for_code_blocks_is_%2522code%2522%2560)~__~__list~___-_Dumbdown_supports_lists~___-_Dumbdown_is_a_demonstration_Tree_Language_from_the_Tree_Notation_Lab~___-_This_is_a_very_early_version~___-_Dumbdown_is_released_to_the_public_domain~___-_If_you_want_to_make_it_better%252C_please_do!~layout_column
You seem open to some feedback, so, here’s some of mine, as someone who’s looked a couple of times at Tree Notation and still hasn’t quite “got it”. I’ve just spent the last 20 minutes looking again at various parts of the site.
(Before I go any further, please be assured this is meant with the best of intentions, and no malice. I feel like there’s something here, and a lot of work has gone into it but somehow I’m not getting it - and I’m not sure what steps I would need to take to get there).
The “What is Tree Notation?” on the front page doesn’t explain what it is, except for the hint “Tree Notation is an error-free base notation like binary”. But I don’t really know what that means.
“Tree Notation […] is grounded in 3-dimensional geometry” (again, from the front page) doesn’t mean anything to me at this point. Honestly, it made me think of Time Cube. I’m sure there’s something there, but I feel intimidated by the idea that I need to understand something mathsy to use Tree Notation. I think I have completely misunderstood what this sentence means, but I also have no idea what it means.
The example with
package.jsonlooks like an alternative syntax for JSON. I think the point is that you can write a syntax for JSON itself in Tree Notation? Which makes it like… JSON Schema? What’s the comparison to something I might be familiar with?The Lisp example is basically the same. It just looks like an alternative grammar: S-Exps without the parens. It’s not obvious how or why this is useful.
On the Grammer section of the front page:
You know, I’d probably lead with this. I think it’s the most concrete information on the page
In the “Who this Library is For” section, I’m unclear what “this Library” is at this point. Is it everything I need to write a language? Is it a parser for tree notation?
The checklist is halfway to being a tutorial. It would be good if it explained the “why” as well as the “what” (and be careful about snipping previously-seen code out of the examples in the tutorial. Much better, IMO, to show all code and note what has changed from the previous block than to elide the code and expect people to remember what it was - don’t make me think ;) )
A walkthrough tutorial for putting this together would probably be super helpful and cool.
Maybe get those written down? Or see if there are common ways it’s being communicated by these people that aren’t currently on the site.
Thank you very much for taking the time. Truly grateful. This is such good data that the current docs are just not doing a good job. I’m thinking perhaps we need to take a much more “show vs tell” approach, with videos, screenshots, animated gifs, visualizations, demos up front, etc, and move the text and FAQ.
You are too nice!
Good point. The more I think about it the more I think the front page should all be show versus tell.
This just means that programs have a 3-D representation. Think of them like molecules. Here’s a video of a talk I gave 2 years ago (https://www.youtube.com/watch?v=ldVtDlbOUMA) that might clarify that more. It was at JSConf 2017 in SF, I’m looking for the actual video and not just my screen recording, but can’t find it. With traditional languages the first step in parsing is to generally strip whitespace and turn the code into a 1D sequence. Your code is not mapped into the 3D world. With Tree Notation it is, and there’s a location of each word/line, and changing that changes the meaning of the program. It’s like a design constraint. Tree Notation programs in a sense need to obey the laws of physics (I know that’s an inaccurate cliche, but might hint at what I’m getting at?).
I’m not familiar with that one, but I totally understand the feedback that this is “A New Kind of Science” type of thing. That’s why I spend most of my time on code, tooling, data gathering, products, user tests and demos and putting the theory into practice, and comparatively little of my time on papers and theoretical work. I’ve tried to see where others who have stumbled upon something similarly simple and perhaps profound have erred. A New Kind of Science has been very influential to me in particular as an experiment of what would it look like to go all in on the theoretical aspect, and my takeaway from that is that it’s a brilliant 50-100 page book, but then it just goes way to far out on a limb and so the priority when dealing with a new library should be to slowly and incrementally build up the tooling to bring practical benefits from the work out early, while putting the theoretical implications as a lower priority. Not descending into madness, while not staying totally practical, while also not listening to people who are trying to disparage the work by saying you are descending into madness, it’s a tricky balance to maintain but I’ve got some good strategies built up to walk that line :)
The Grammar Tree Language is sort of like JSON Schema. I just updated that example a bit with more information. Tree Notation is very low level (think binary or ascii). The Tree Languages can do anything (so you can have a Tree Language that maps to JSON like the Dug demo language, or you can make a Tree Language for building languages like Grammar, or you can make a general purpose Tree Programming language, etc). The idea is none of those things require parens or brackets or colons etc. Simple positioning in 3D geometry is the only thing we need to do all of the things that we traditionally use syntax for. Positioning gives you abstraction, scope, trees, etc. The building blocks for everything else.
If you look at any one example you can say they all are only incremental improvements. It’s all about the network effects. I did not write syntax highlighting for my lisp like Tree Language. I wrote it for my HTML Tree Language. But It works for both. Etc. If you master the basics of Tree Notation syntax (maybe there’s like 5 rules? I’m not sure how many but it’s less than 10 for sure), you understand the syntax for now dozens of languages (and hopefully in the future, thousands). The semantics you need to learn from that domain, but hopefully we eliminate one large category of mistakes and confusion.
Good idea. Thanks! Will probably do that in the new version.
This is a common point of confusion. We should reorganize it so there’s the Tree Notation landing page, and then there’s the JTree Landing page (the tree notation library for TypeScript/Javascript). In the new redesign, we’ll remove the Jtree specific stuff and instead add links to all the different implementations, similar to json.org.
Good feedback! Thanks. Someone is volunteering to do a new one. Hopefully he’ll post that soon.
Noted. Will add..
Great idea. I just sent an email to the lab folks. Will add.
Yeah, videos would be great.
How quickly you can use it is not a great signal, because it’s your baby and you’ve created it from scratch. Needs more hallway usability testing.
Yeah, it’s painful in this regard. Yesterday’s designer launch addressed a number of the most common issues, but still the list of things to do and user requests is a mile long. The in person community here is very helpful, but hoping we’ll be able to get a community going of remote contributors in the months ahead.
Agreed. It’s what I have though, until the tooling gets better. I guess the promising signal though is that this sort of thing would have taken me 10 hours or more 6 months ago (speaking in rough estimates), so the trend is in the right direction.
There’s a thing at work we’re currently representing rather clumsily with JSON that I’ve been wanting to find a better encoding for. Defining a tree language for it, and a back-and-forth converter between tree notation and the current JSON might be a cheap experiment to see what it’s all about.
If tree notation is as useful as you make it sound, that could be a huge productivity boost. It sounds like it could make it easier for people to edit these structures by hand, to write more advanced features for the visual editor, create automatic transformations of common patterns, and so on.
You have me intrigued.
Please do let me know how it goes.
I apologize in advance for the difficulty as the current state of things is early, but appreciate any help toward making things better for the future community!
This is very cool. A good example of what tree notation is and how it’s actually useful.
Glad you like it! I have loved markdown over the years, so think an evolved, simpler form will be useful.
Is there any way to import/source files into another, or references the same tree node at multiple places?
In dumbdown or the grammar language?
Grammar files: We are exploring adding imports/exports via the filesystem, or even via urls or some type of registry, but nothing at the moment. The current solution is just to concat the two files together (the last root node becomes the root node for the new combined grammar), generally via a build step. As far as I know this is the simplest grammar concatenation language ever devised (but I could be wrong). Here’s an example that adds a comment node type (https://github.com/treenotation/jtree/blob/master/langs/jibjab/jibjab.gram) to the jibberish language and calls the new resulting language “jibjab”.
For dumbdown no, but I’d be interested in seeing if people tried that. I could see it could be helpful for something like a book language. But I wonder if the build/concat approach would be best for that situation as well.
In Grammar you can reference nodeType definitions and/or cellType definitions in multiple places. Not sure specifically if that’s what you are talking about, or something else? At the Tree Notation level there is no concept of a symlink. That is something that needs to be defined at the Tree Language level. Though some people have suggested adding some type of reference syntax to the tree notation level (something like http://ogdl.org/), I haven’t yet found a way that is simple and antifragile. Perhaps the best way to do it is just to combine the number in the cell (treating a word as just a number) coupled with the location of the cellType definition in a grammar to triangulate a reference.
Yes, I was thinking of “symlink” nodes, much like leo-editor has. I was thinking something like named nodes, where the same place in a tree can (de)reference another node component, and changes to that node are reflected in all refs - much like if you imported it into a position in a tree.
“Outline nodes may appear in more than one place, allowing multiple organizations of data within a single outline.”
I’m not sure I understand this. Is this just projectional editing? For example, on https://ohayo.computer you can edit the source by hand on the left or edit things with your mouse on the right.
Or is it just symlinks/imports? I have a lot of languages that are simply the result of concat’ing “gram” files into “grammars”, and if you change one “gram” file that is imported by multiple languages you update all those languages, though I currently implement that as a build step and not in the language itself.
Leo looks very interesting. It seems familiar, but I can’t recall seeing it or find any notes on it, at the moment, so could be new to me. Thanks for sharing.
@breck this link appears to be down, I’m getting 404 (at 14:43 Sunday, 22/Sept IST)
Thanks for the note! The new link is: http://jtree.treenotation.org/designer/#standard%20dumbdown
I’ve added this to a bug tracking the broken links: https://github.com/treenotation/jtree/issues/65