5 ms·

> Brooks dared to predict I love this. So rare nowadays to scientists make bold predictions. Disclosure: I work on Tree Notation (https://treenotation.org/ ht

by breck 7y ago

> Brooks dared to predict I love this. So rare nowadays to scientists make bold predictions. Disclosure: I work on Tree Notation (https://treenotation.org/ https://treenotation.org/). Two years ago, in 2017 I predicted Tree Notation will be a silver bullet: by 2027 we will have a 10x improvement in reliability, productivity, and simplicity, thanks to the Tree Notation ecosystem. 2 years later, and thousands of experiments and conversations later, I'm almost positive that will happen.

bearer_token 7y ago
Okay, I'll bite. How is this different than an Abstract Syntax Tree (AST)?
- breck 7y ago
 Think of your code in a spreadsheet or Cartesian plane. Each word has a location in 2D space. There is a physical manifestation of your program’s source code. The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code. So source == AST. Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
 - heavenlyblue 7y ago
 How is that different from XML?
 - breck 7y ago
 In XML: <a></a> === <a> </a> In Tree Notation those are 2 different structures.
 - bobbiechen 7y ago
 Interesting. Would you say this is similar to a visual programming language like Max/MSP? I was always intimidated by the large screens of spaghetti (almost literally, because of patch cords). How do you deal with large complex code? Lots of folding?
 breck 7y ago
 Max MSP is definitely an inspiration of mine. Tree Notation is just a format, however. It could be an ideal way for a program like max to store its documents in, as opposed to an xml or a Json. It would allow dual visual / source editing. See our ohayo beta for an example. (note to self: add ohayo demo video) Large complex code hasn’t turned out to be too difficult yet. The key is well designed tree languages for the task at hand. Also, sublime text helps :). Have some code bases in the 6 digits loc. It’s all about tooling though. I don’t really use folding yet but perhaps that would be another feature that can make things easier, good suggestion. Things like type checking, syntax highlighting, auto complete, are essential.
 - heavenlyblue 7y ago
 How are they different? In XML you would need to insert tags defining the whitespace so that it would be seen by programs operating on the AST. Are your “two different structures” any different from the same representation in XML?
 breck 7y ago
 This is a good point. When building a raw xml parser, these would be 2 different things. I think it’s a fair analogy to say tree Notation is just a much simpler XML. At least 2x as simple: <proof></proof> proof
lidHanteyk 7y ago
You should make a Long Bet for it. Every lambda calculus, including yours, corresponds to a Cartesian closed category. Your system is not at all as new as you think; what you are actually inventing are new ways to write down parsers, akin to the many other ways that folks are trying to write down programs in JSON or XML or YAML. The only advantage that you've got at this point is a 2D addressing scheme, you might think, but E had that in the late 90s: http://www.erights.org/elang/kernel/LiteralExpr.html http://www.erights.org/elang/kernel/LiteralExpr.html
- breck 7y ago
  > You should make a Long Bet for it. Second time I heard this suggestion (https://news.ycombinator.com/item?id=20504193 https://news.ycombinator.com/item?id=20504193), thanks! Done. http://longbets.org/793/ http://longbets.org/793/ - “In 2027, at least 7 out of the top 10 TIOBE languages will be Tree Languages AND/OR 0 out of the top 10 languages on 2017's list will be in the Top 10 in 2027. ” > Your system is not at all as new as you think I agree. It's mildly new. Tiny tiny little details that make a big difference in practice. To get here I had to stand on the shoulders of giants: built the largest DB of computer languages in the world (over 10k languages with over 1k columns). > but E had that in the late 90s Great reference, thanks. E and Kernel-E are great, but the devil is in the details. There are a tremendous amount of tiny little details in Tree Notation and Tree Language that compound to make this something new. You can't take anything out of Tree Notation without losing something important. Everything else you can add via a Tree Language. That makes this closer to binary, imo. There are at least a dozen things that could be taken out of Kernel-E, which itself is a subset of E.
  - heavenlyblue 7y ago
    What exactly makes Tree Language any different from the context-sensitive encoding of code in binary?
    - breck 7y ago
      Abstraction. Scope. (also, usability?) Interesting question though. Can you elaborate?
solipsism 7y ago
From your website... By 2020, we expect Flow to be a competitive rival to Python or R for 80% of data science tasks. That's incredibly ambitious. Checking in -- are you within 4 months of reaching that goal?
- breck 7y ago
  Yes, despite how it looks. Flow/Ohayo version 17 should hit that. About to ship version 14.

by breck 7y ago

bearer_token 7y ago

Okay, I'll bite. How is this different than an Abstract Syntax Tree (AST)?

breck 7y ago
Think of your code in a spreadsheet or Cartesian plane. Each word has a location in 2D space. There is a physical manifestation of your program’s source code. The parsed version (with the words of your source replaced with their parsed types), has the same shape (physical manifestation) as your source code. So source == AST. Currently traditional languages this is not true. They are stripped to 1D and the further you move from lisp the more different they become.
- heavenlyblue 7y ago
 How is that different from XML?
 - breck 7y ago
 In XML: <a></a> === <a> </a> In Tree Notation those are 2 different structures.
 - bobbiechen 7y ago
 Interesting. Would you say this is similar to a visual programming language like Max/MSP? I was always intimidated by the large screens of spaghetti (almost literally, because of patch cords). How do you deal with large complex code? Lots of folding?
 - breck 7y ago
 Max MSP is definitely an inspiration of mine. Tree Notation is just a format, however. It could be an ideal way for a program like max to store its documents in, as opposed to an xml or a Json. It would allow dual visual / source editing. See our ohayo beta for an example. (note to self: add ohayo demo video) Large complex code hasn’t turned out to be too difficult yet. The key is well designed tree languages for the task at hand. Also, sublime text helps :). Have some code bases in the 6 digits loc. It’s all about tooling though. I don’t really use folding yet but perhaps that would be another feature that can make things easier, good suggestion. Things like type checking, syntax highlighting, auto complete, are essential.
 - heavenlyblue 7y ago
 How are they different? In XML you would need to insert tags defining the whitespace so that it would be seen by programs operating on the AST. Are your “two different structures” any different from the same representation in XML?
 - breck 7y ago
 This is a good point. When building a raw xml parser, these would be 2 different things. I think it’s a fair analogy to say tree Notation is just a much simpler XML. At least 2x as simple: <proof></proof> proof

lidHanteyk 7y ago

You should make a Long Bet for it. Every lambda calculus, including yours, corresponds to a Cartesian closed category. Your system is not at all as new as you think; what you are actually inventing are new ways to write down parsers, akin to the many other ways that folks are trying to write down programs in JSON or XML or YAML. The only advantage that you've got at this point is a 2D addressing scheme, you might think, but E had that in the late 90s: http://www.erights.org/elang/kernel/LiteralExpr.html http://www.erights.org/elang/kernel/LiteralExpr.html

breck 7y ago
> You should make a Long Bet for it. Second time I heard this suggestion (https://news.ycombinator.com/item?id=20504193 https://news.ycombinator.com/item?id=20504193), thanks! Done. http://longbets.org/793/ http://longbets.org/793/ - “In 2027, at least 7 out of the top 10 TIOBE languages will be Tree Languages AND/OR 0 out of the top 10 languages on 2017's list will be in the Top 10 in 2027. ” > Your system is not at all as new as you think I agree. It's mildly new. Tiny tiny little details that make a big difference in practice. To get here I had to stand on the shoulders of giants: built the largest DB of computer languages in the world (over 10k languages with over 1k columns). > but E had that in the late 90s Great reference, thanks. E and Kernel-E are great, but the devil is in the details. There are a tremendous amount of tiny little details in Tree Notation and Tree Language that compound to make this something new. You can't take anything out of Tree Notation without losing something important. Everything else you can add via a Tree Language. That makes this closer to binary, imo. There are at least a dozen things that could be taken out of Kernel-E, which itself is a subset of E.
- heavenlyblue 7y ago
  What exactly makes Tree Language any different from the context-sensitive encoding of code in binary?
  - breck 7y ago
    Abstraction. Scope. (also, usability?) Interesting question though. Can you elaborate?

solipsism 7y ago

From your website... By 2020, we expect Flow to be a competitive rival to Python or R for 80% of data science tasks. That's incredibly ambitious. Checking in -- are you within 4 months of reaching that goal?

breck 7y ago
Yes, despite how it looks. Flow/Ohayo version 17 should hit that. About to ship version 14.