Hacker News Reader

Comment by breck | Hacker News Reader

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.

View on HN

That Tree Notation? 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.

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/

It looks like a toy, but this will change everything.

Or I could be wrong.

https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...

I still don't see what's different.

> Parsed as a linear sequence of tokens, transformed to an AST, compiled.

So are the Tree Notation programs. They are parsed as linear sequence of tokens -- when I look at the https://jtree.treenotation.org/designer/ , the inputs are 1-d sequence of characters separated by spaces and newlines. Those are parsed one at a time, and make a tree structure.

If the "2 dimensionality" refers to the fact that you have lines (Y dimension) and each line is split into words (X dimension), then this is not very new either -- this is how TCL and Unix shells view the world.

> I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages.

I see no evidence of it. What can Tree Notation do that lisp/scheme can't?

> In Tree Notation the shape of your source code is immutable during parsing.

Are you talking about how characters on the screen correspond to nodes of your AST tree? If yes, than this seems extremely limiting. Each screen line is not that long -- probably 120 characters is a reasonable limit. What if you want a longer payload? What if in the output of your program has nodes with longer payload which no longer fit on the screen?

Or is the idea that you take complex tree language, like s-expr, and _restrict_ it so it is representable as punctuation-free text? I guess this could be cool for education values, but I fail to see how such restrictions make the language "chasmically superior"

> The AST and CST have the same shape.

Like Lisp programs?

> Tree programs are isomorphic to geometric trees.

So are Lisp programs.

> Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning

Are you talking about character recognition or text parsing? The former is in parallel, but the latter is not. You can test it yourself trivially -- press the Zoom button in your browser. The font size changes, all the words move around, but you can still parse the text just fine.

> Computers can to. And my bet is that they will.

They already do! All the image recognition tasks (including character recognition) look at all the letters in parallel. You might have heard about this technology, it is called "neural networks". Moreover, they made special chips which work on a huge _2-dimensional_ matrix of numbers all at the same time!

> but this will change everything. Or I could be wrong.

I am not sure what is there to change, given that every part has been successfully used for many tens of years.

> So are the Tree Notation programs.

Today's machines impose a way of doing things. But in the future there will be a new type of machine. In the interim we can harvest a lot of benefits from Tree Languages by working within the constraints created by today's register model of computing.

> on the screen

The vast majority of research and experimentation with Tree Notation does not happen on the screen at all. Experiments are done in higher dimensions in different mediums.

> So are Lisp programs.

No they're not. There is a proof out there somewhere from 2017 proving why they are not.

The 2-D layout is not an "afterthought". It is not a "beautified" version of Lisp. The 2-D layout is an essential ingredient of Tree Notation. You can change the rules of Lisp/SExp to achieve the same 2-D layout, and what you end up with is Tree Notation! So while Tree Notation can be thought of as one way to write S-Expressions, it's a very special way that has a 2-D geometric isomorphism that (this does not have). And that goes on to make a huge difference.

> Today's machines impose a way of doing things. But in the future there will be a new type of machine. [...] working within the constraints created by today's register model of computing.

Which "way of doing things" would that be, and how exactly is this constraining us? Sure, most physical CPUs do use registers, but a lot of languages define their own machine model which are not register-based. We have stack-based machines, vector-based machines, matrix-based machines, the functional languagues with tree evaluation models, declarative programming, and lots more.

> No they're not. There is a proof out there somewhere from 2017 proving why they are not.

I searched for this proof, and all I could find is this FAQ entry: https://faq.treenotation.org/#how-is-this-different-from-s-e...

faq> How is this different from S-Expressions?

faq> It is largely accurate to say Tree Notation is S-Expressions without parenthesis. But this makes them very different! Tree Notation gives you fewer chances to make errors, easier program concatenation and ad hoc parser writing, easier program synthesis, easier visual programming, easier code analysis, and more.

This looks like a restricted subset of lisp's s-expressions. And the explanation only talks about incremental improvements over s-expr, not radically new capabilities.

Is there a better document I have missed?

> it's a very special way that has a 2-D geometric isomorphism ... that goes on to make a huge difference.

Are we talking about geometric isomporphism in the mathematical sense, as in graph embedding on a plane? If yes, I am very interested to see what kind of useful results one can get out of it. While graph embedding is useful for certain problems, it seems generally inapplicable for the common computing tasks.

Or even better, is there a sample code which demonstrates the advantages of isomorphism? The biggest sample code I found was "Grammar"[0] and it seems to be sadly one-dimensional...

[0] https://jtree.treenotation.org/designer/#standard%20grammar

> physical CPUs do use registers

This. Imagine you didn't have to transform a program into a thousand permutations to execute on 1D registers. Imagine just loading the program into 2D/3D registers and having it compute the result in a single cycle.

AFAIK no one has ever built these higher dimensional registers before (done some searching, asked Vinod once, and a number of other cpu folks but no one gets it), but I'm very confident (10%) they will work and be better than quantum, but I don't have the money to fire at a rocket pace so this will take time. I've pitched it to DARPA, and do expect them at some point to take it up.

> I searched for this proof

Sorry, I thought I made a latex version of this somewhere. I found some old notes that I uploaded:

https://github.com/treenotation/research/blob/master/lisp/re...

> Or even better, is there a sample code which demonstrates the advantages > of isomorphism?

One of the more recent ones that starts to hint at the benefits of a 2-D syntax and the isomorphism is this video: ("If Spreadsheets and Programming Languages had a baby")

https://www.youtube.com/watch?v=vn2aJA5ANUc

> Imagine just loading the program into 2D/3D registers and having it compute the result in a single cycle.

You mean like SSE extensions in Intel CPUs, which can operate at 64 bytes at a time, potentially doing 64 operations in a single cycle?

Or FPGAs, which can have an arbitrary wide registers -- I have seen a design where entire video scanline, 600+ points, is processed in one cycle?

Or video cards, which have multiple parallel executors -- a high-end NVIDIA card can process 64x64 pixels in parallel, with each pixel getting its own little execution core.

Or maybe famous Cray 1 machine [0], which had a vector instructions, such as "a single instruction a(1..1000000) = addv b(1..1000000), c(1..1000000)"

Or maybe a Connection Machine? It sounds as close to 3-D machine as you can make it -- it even had 3-D shape with bits arranged in cube [1]:

> The CM-1, depending on the configuration, has as many as 65,536 individual processors, each extremely simple, processing one bit at a time. CM-1 and its successor CM-2 take the form of a cube 1.5 meters on a side, divided equally into eight smaller cubes.

Your say that "no one has ever built these higher dimensional registers" -- but as you can see, there are plenty of examples one can come up with. It is entirely possible that your idea is different from all of these, but it is not clear how. I think your website would benefit greatly from the comparison with those other computing devices, as well as more details as to what this "tree architecture" looks like -- how many ALUs, memory blocks, instruction decoders etc.. do you want to have and how are they interconnected.

[0] https://en.wikipedia.org/wiki/Cray-1

[1] https://en.wikipedia.org/wiki/Connection_Machine

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.

Visual inherently opens the product up to non-developers, which is where a lot of the commercial opportunity lies.

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.

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..."

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.

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.

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

Discovery of tree notation, are you kidding me?

https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8

:-)

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.

Probably not. I hadn't heard of Tree Notation before. Do you have a useful comment to make on it?

https://mathworld.wolfram.com/Tree.html

https://www.math.ru.nl/OpenGraphProblems/TimV/notationsandde...

Thank you, but I know what a tree is. I believe they were specifically referring to https://treenotation.org/

That's the thing I hadn't heard of and would be interested to hear if someone had tried applying it in real world scenarios.

Reply on news.ycombinator.com