4 ms·

What you want is "low code". Or less rhymey but more accurate: "minimal code". Historically visual programming tools did not create this. In fact they generate

by breck 6y ago

What you want is "low code". Or less rhymey but more accurate: "minimal code". Historically visual programming tools did not create this. In fact they generated very bloated code. So visual programming tools got a bad rap. But there's no inherent reason why they need to generate bloated code. And if well done they can indeed generate minimal code (and program synthesis advancements will help a lot here). We worked on this from ~2010 at Nudge and we eventually solved it with the discovery of Tree Notation.

k__ 6y ago
Why does it have to be visual? If I can use a library or a framework that saves me from writing thousands of LoC, that's low-code too.
- iamacyborg 6y ago
  Visual inherently opens the product up to non-developers, which is where a lot of the commercial opportunity lies.
  - josho 6y ago
    Visual vs code masks the real concern which is people that can analyze a problem, decompose it to smaller parts. I’m not convinced that the new tools make that problem any easier except for the most trivial problems.
  - the_af 6y ago
    If they are going to write non trivial code, they better be developers. Corollary: all trivial code expands, little by little, into a non trivial beast. Years later, developers dealing with the mess are going to ask why things are the way they are, and they are going to be told "this was started by people with little coding experience, it was supposed to be a throwaway minor thing..."
- breck 6y ago
  It doesn’t. I think just often, including in the OP, the term no/low code is used to speak about the visual subset of the problem. I agree with you in that higher level text abstractions are low code as well.
auggierose 6y ago
Discovery of tree notation, are you kidding me?
- breck 6y ago
  https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8 https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8
  - auggierose 6y ago
    :-)
  - auggierose 6y ago
    Haha, I checked out tree notation in more detail just now, and I actually agree absolutely with one of the underlying hypotheses: that whitespace is essential for languages. You are taking it to the extreme by immediately just looking at one particularly easy to parse use of whitespace that directly corresponds to trees where inner nodes can have data too. My work is very related, I was also inspired by the fact that whitespace is essential. I have developed a grammar semantics that is more expressive than both context-free grammars and parsing-expression grammars, and unifies lexing and parsing by seeing them as two different sides of the same coin (namely, terminal symbols, and nonterminal symbols). It is basically just a generalisation of Earley parsing, and some of the puzzle pieces just fell into place for me a few months ago while I was writing a grammar for a Markdown like language. One problem is that it possibly inherits the same performance problems as Earley parsing, but I am thinking that this can be fixed by having the top-level(s) in a simple tree-notation like yours that can be parsed in parallel. You can also write grammars that accept any input, and so you can check for errors just by checking if certain grammar symbols corresponding to errors are present in the parse tree or not, but the parsing itself will never fail. But I don't have an automatic way of checking if a particular grammar has that property. I also agree with you in that trees are really important :-) I am working on a tool and libraries for working with my grammars, and I've decided that all output will be standardised as trees in a simple matter by classifying grammar symbols along two different axes: a) flat vs. nested, and b) auxiliary vs. visible. Based on that division, parse trees are created automatically. This makes things much simpler for now, and (I hope) allows for more composable and modular grammar design.
protomyth 6y ago
What you want is "low code". Or less rhymey but more accurate: "minimal code". Kind of. What I really want is something that can round-trip to a textual representation and is heavily visual with the possibility of adding custom actions. I guess a BizTalk Orchestration built from the start to be a programming tool. I often think in my retirement I am going to take a crack at doing Excel as graph of tables and components.
- Huggernaut 6y ago
  I might have misunderstood your want but perhaps you'd be interested in where we're going with Storyscript? [1] We're working on a primarily text, multi-modal "low-code" experience. Or maybe you're suggesting the other way round, that you want primarily visual but with a way to interact with it in a text based format? 1. https://storyscript.com https://storyscript.com
theamk 6y ago
That Tree Notation? https://treenotation.org/ https://treenotation.org/ I don't get it. The descriptions are pretty wild and make little sense to me: > Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing. But in practice, we have: - Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes. - Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output. - A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs? Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.
- breck 6y ago
  Your observations about the specifics are fairly good. The big idea is about dimensionality. All of the TIOBE languages are 1-dimensional. Parsed as a linear sequence of tokens, transformed to an AST, compiled. I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. Tree Notation is one very useful implementation of this bigger idea. In Tree Notation the shape of your source code is immutable during parsing. The AST and CST have the same shape. More abstract nodes stack up the z-axis like you would stack legos. Tree programs are isomorphic to geometric trees. Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning (as opposed to position in a linear sequence). Computers can to. And my bet is that they will https://longbets.org/793/ https://longbets.org/793/ It looks like a toy, but this will change everything. Or I could be wrong. https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkHk77nStQSGxgi https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...
  - 6y ago

by breck 6y ago

k__ 6y ago

Why does it have to be visual? If I can use a library or a framework that saves me from writing thousands of LoC, that's low-code too.

iamacyborg 6y ago
Visual inherently opens the product up to non-developers, which is where a lot of the commercial opportunity lies.
- josho 6y ago
  Visual vs code masks the real concern which is people that can analyze a problem, decompose it to smaller parts. I’m not convinced that the new tools make that problem any easier except for the most trivial problems.
- the_af 6y ago
  If they are going to write non trivial code, they better be developers. Corollary: all trivial code expands, little by little, into a non trivial beast. Years later, developers dealing with the mess are going to ask why things are the way they are, and they are going to be told "this was started by people with little coding experience, it was supposed to be a throwaway minor thing..."
breck 6y ago
It doesn’t. I think just often, including in the OP, the term no/low code is used to speak about the visual subset of the problem. I agree with you in that higher level text abstractions are low code as well.

auggierose 6y ago

Discovery of tree notation, are you kidding me?

breck 6y ago
https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8 https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8
- auggierose 6y ago
  :-)
- auggierose 6y ago
  Haha, I checked out tree notation in more detail just now, and I actually agree absolutely with one of the underlying hypotheses: that whitespace is essential for languages. You are taking it to the extreme by immediately just looking at one particularly easy to parse use of whitespace that directly corresponds to trees where inner nodes can have data too. My work is very related, I was also inspired by the fact that whitespace is essential. I have developed a grammar semantics that is more expressive than both context-free grammars and parsing-expression grammars, and unifies lexing and parsing by seeing them as two different sides of the same coin (namely, terminal symbols, and nonterminal symbols). It is basically just a generalisation of Earley parsing, and some of the puzzle pieces just fell into place for me a few months ago while I was writing a grammar for a Markdown like language. One problem is that it possibly inherits the same performance problems as Earley parsing, but I am thinking that this can be fixed by having the top-level(s) in a simple tree-notation like yours that can be parsed in parallel. You can also write grammars that accept any input, and so you can check for errors just by checking if certain grammar symbols corresponding to errors are present in the parse tree or not, but the parsing itself will never fail. But I don't have an automatic way of checking if a particular grammar has that property. I also agree with you in that trees are really important :-) I am working on a tool and libraries for working with my grammars, and I've decided that all output will be standardised as trees in a simple matter by classifying grammar symbols along two different axes: a) flat vs. nested, and b) auxiliary vs. visible. Based on that division, parse trees are created automatically. This makes things much simpler for now, and (I hope) allows for more composable and modular grammar design.

protomyth 6y ago

What you want is "low code". Or less rhymey but more accurate: "minimal code". Kind of. What I really want is something that can round-trip to a textual representation and is heavily visual with the possibility of adding custom actions. I guess a BizTalk Orchestration built from the start to be a programming tool. I often think in my retirement I am going to take a crack at doing Excel as graph of tables and components.

Huggernaut 6y ago
I might have misunderstood your want but perhaps you'd be interested in where we're going with Storyscript? [1] We're working on a primarily text, multi-modal "low-code" experience. Or maybe you're suggesting the other way round, that you want primarily visual but with a way to interact with it in a text based format? 1. https://storyscript.com https://storyscript.com

theamk 6y ago

That Tree Notation? https://treenotation.org/ https://treenotation.org/ I don't get it. The descriptions are pretty wild and make little sense to me: > Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing. But in practice, we have: - Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes. - Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output. - A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs? Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.

breck 6y ago
Your observations about the specifics are fairly good. The big idea is about dimensionality. All of the TIOBE languages are 1-dimensional. Parsed as a linear sequence of tokens, transformed to an AST, compiled. I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. Tree Notation is one very useful implementation of this bigger idea. In Tree Notation the shape of your source code is immutable during parsing. The AST and CST have the same shape. More abstract nodes stack up the z-axis like you would stack legos. Tree programs are isomorphic to geometric trees. Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning (as opposed to position in a linear sequence). Computers can to. And my bet is that they will https://longbets.org/793/ https://longbets.org/793/ It looks like a toy, but this will change everything. Or I could be wrong. https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkHk77nStQSGxgi https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...
- 6y ago