[breck]

I use spreadsheets and custom 2D dsls. I get the best of tabular and tree structures. The latest iterations aren’t live yet, but there’s a lot of stuff on treenotation.org which is the foundation of what I use.

I consider it like a tool for clear thinking. There’s no punctuation or noise, pure signal. I build DSLs and then spreadsheets in those DSLs. Both the data and grammars are in 2D Lang’s. There’s no quotes, brackets, patents, etc. Everything is strongly typed (eventually, in practice I start with a lot of “any” fields and iterate on the ontologies as my knowledge of a domain grows).

Everything is backed by git.

I do a lot of visual modeling lately with my remarkable 2 eink tablet.

[wuschel]

Hi, I had a look at treenotation.org and some of your other resources - could you perhaps post a practical example on how you use your custom 2D DSLs, and why it would be preferential to other tools?

[breck]

Here's a 2 minute video explaining one example: https://www.youtube.com/watch?v=0l2QWH-iV3k

[wuschel]

Thank you for the video URI, and for taking the time to get to back to me!

I am still trying to identify what makes your technical solution unique and better that, say, a Jupyter/Dataframe based system.

1) It seems to me that most of the commands that have to be done in a UI with Google Docs/Excel can now be written down and immidiately resolved in your hybrid solution. That probably opens a path towards diffing/version control. Type checking is very nice, though.

2) The spreadsheet like UI probably makes it easier to edit data, although that is something I would like to play arounnd with.

Also, I am trying to understand the key conceptional differentiators. What do you mean by 2D language?

[breck]

First, a caveat. I wouldn't advise using Tree Notation if you had an urgent need and aren't in this for at least a year, as the benefits accrue over time and will only really become impactful as the ecosystem grows. With that out of the way, let me address your questions.

> I am still trying to identify what makes your technical solution unique and better that, say, a Jupyter/Dataframe based system.

It's a low level symbolic notation. Any symbolic notation is an imperfect way to model reality. Some are better than others. I propose that Tree Notation may be the best such symbolic notation we have ever come up with. I measure "best" here as a function of capabilities and complexity. Tree Notation has all the capabilities of other symbolic notations (you can build a "data structure zoo" and you'll find that every structure has a representation in Tree Notation), without the complexities of extraneous syntax. You simply have words. You have no quotes, no parens, brackets, etc. Words laid out in geometry. Sure, about 1% of languages have done the "indent significance", such as in Python and YAML, but no one (until Tree Notation) figured out that that's all you need. You don't need any other syntax characters. Simply have rows and columns (and using indents for scope) is enough. This "simple as possible" pays dividends. For example, simple new ways to count complexity (https://jellypbc.com/posts/ezmntq-counting-complexity).

As a low level notation, you can't compare something like Jupyter/Dataframes directly to it. That would be like comparing Jupyter/Dataframes to binary notation. However, you can compare Jupyter/Dataframes to a higher level tool built on Tree Notation, such as Ohayo (http://ohayo.computer/). What does Ohayo have that Jupyter doesn't? Well it's a very high level language where you can mix data and code easily. Coding with it is very copy/paste friendly. Whole programs can be put in the URL. There's no server side backend needed—everything runs locally in your browser. Of course, there's no ecosystem or community behind Ohayo yet, but the nice thing about Tree Notation is that simplicity doesn't go out of style. If at some point the resources spring up to develop it further, I think it could be a very popular tool and community.

There's nothing semantic you can do in Tree Notation that you can't do in Jupyter/etc, as for the foreseeable future they all are running on the same hardware. But it's very pleasant to write tooling and parsers for Tree Notation since it's so simple, and as a user you get great things like seamless semantic interop with git, pleasant copy/pasting, url friendly programs, et cetera.

> Also, I am trying to understand the key conceptional differentiators. What do you mean by 2D language?

All existing 10,000+ computer languages I would call "1-D". That is, it is assumed that you have 1 read head that moves linearly along the program generally from beginning to end. Tokenizing happens, white space is stripped, an AST is built, compilations occur. 2-D languages don't have the same assumptions. You could potentially have multiple read heads. Read heads could move not just back and forth, but up and down. Of course, it will be a while before we have 2-D registers, and so for a long while we still have to compile to 1D langs, but there's a future where computing looks a lot different than today.

Another way to think of it is that currently programs are roughly transformed into a ticker tape and read linearly in order. 2D programs don't have to be, and could be read by the computer similar to how a human reads a newspaper—parsing and zooming in and out in potentially random order.

A much simpler more pragmatic definition for now could just be that a certain subset of TSV is a 2D language.

[wuschel]

Breck,

many thanks for the very detailed response to my questions. I wish I could upvote you more than once.

I am looking at your paper/cited literature to understand a bit more about your work. At first, my initial thoughts were that this is very similar to a Lisp derivative. I now see that indeed there is a second axis in place, be it via tabs or cells.

Thank you also for the link to Ohayo.computer. I will check it out, and try to fool around a bit with the 2-D lang concept.

Cheers,

  piotr