Though it's hard once again to understand. When are two nodes coincident? By definition you can only have one character in one place on the screen. Is he talking about indentation, that the same level of indentation can mean different things? That seems true of ETN as well, from what I can tell.
The pencil scratchings on the screenshots don't help either.
Sorry, the lines in the geometric mapping of the source code are coincident. In drawing B) in the visual proof, the edges which connect the child nodes to their parents intersect and/or are coincident. So when you put Lisp source code onto graph paper, and draw boxes around the nodes, and line segments for edges, it shows why Lisp source is not a geometric language (I define a geometric language as one where there are no intersecting or coincident line segments).
Now, figure A) shows the same Lisp code, formatted differently, in a way that is a geometric language. But as you can see, that code is standard TN/ETN. Or perhaps another way to put it is ETNs are just Lisps with a whitespace syntax and no parentheses. Another reader on HN pointed me to I expressions (https://srfi.schemers.org/srfi-49/srfi-49.html), which I hadn't seen before and is 90% of the way there to TN and ETNs. The creator of I-Expressions have communicated briefly over email now and are going to be talking soon.
Anyway, perhaps another term for Tree Notation/ETNs is "Geometric Lisp", or "2-Dimensional Lisp". I'm not wedded to the terms TN/ETNs, although I do think it's better to have new terms, because I think these will come to dominate the usage of Lisp.
Still working on more updates and evidence on why I think these will be so big.
I thought all the emphasis of how great it was made it harder for people to understand _what_ "it" was. Probably a good idea to keep an initial post like this matter-of-fact. Motivate it with just one simple strength that's easiest to communicate. Describe the broader context and implications in a separate post, later, after people understand what it is.
I totally agree. Although perhaps I wouldn't have gotten as much feedback had I taken a more modest approach? Hard to say. I still haven't done a good job communicating the benefits of ETNs yet, stemming from their 2D/geometric nature. Almost got version 1.1 of Ohayo done which makes another step toward that.
That motivation makes sense. Bear in mind, though, that the "less modest" approach has a limited amount of gas. It will stop working at some point.
I can relate with having these questions and considering the different strategies as well. If you really think that this is going to be your life's work, it's reasonable to burn some 'reputation' to get the word out. However, I've often been wrong before. Now I tend to err on the side of playing a long game.
Over time I've gained respect for the essential wisdom of this quote:
"We knew that Google was going to get better every single day as we worked on it, and we knew that sooner or later everyone was going to try it. So our feeling was that the later you tried it, the better it was for us because we’d make a better impression with better technology. So we were never in a big hurry to get you to use it today. Tomorrow would be better." -- Sergey Brin, as retold by Seth Godin in "The Dip"
Applicable to ideas like here just as much as products.
Wow, what a quote! That's exactly how I feel about Ohayo. That seems like a better approach--not to be in a big hurry to get people to use it today. Thank you akkartik. Really appreciate that advice!
My only concern pre-launch and announcement, was that I was going to get hit by a bus and the world would have to wait longer for someone else to stumble upon (and popularize) TN and ETNs. Now that it's out there and a few thousand people have seen it, I can take this more sensible approach.
Btw, just pushed version 1.1.0 if anyone's interested.
UX still needs work, but I rushed adding a "3D block" to the flow language, (using the vis.js library), so you can start to see what "3D" code looks like.
Yes, the atstrings feature is turned off by default in Arc 3.1 (and also in Anarki's official/stable branches). I think I'll turn off the default in Anarki as well, and just let news.arc continue to make use of it.
Edit 1 hour later: This is now done. Turns out Anarki never meant to turn on atstrings by default. This was a side effect of loading news.arc by default (mea culpa). I've changed things so we load news.arc by default but only use atstrings in news.arc by default. Keep an eye out for subtle bugs introduced by atstrings being turned off when functions in news.arc are called. If we see any I'll probably take out the ability to turn it on and off and just decide to keep it everywhere or take it out entirely.
I don't know if I'd ever want to use this 2D syntax directly, but I'll probably "use" it as a thought experiment for non-hierarchical syntaxes, along with cellular automata and spreadsheets. :)
Can you imagine an 'unquote-splicing operation for this tabuleau syntax? Between lists, 'unquote-splicing can insert any list into any other, but the cells of these tables have externally imposed sizes and shapes, so for an 'unquote-splicing in a table (if we wanted one at all), we'd probably want to enforce that the sizes and shapes match up in a way that makes sense. What might make more sense is to do 'unquote-splicing in a full row or column at once, because at least we get one dimension of freedom that way. If the splice takes up a full row, then it can splice in any number of rows (of any height) to that location.
I'm probably a little obsessed with quasiquotation lately. I've been trying to write an implementation of a macro system where the meanings of notations like 'unquote, 'unquote-splicing, and parentheses themselves can be treated as user-defined macros, and where syntax-bound concepts like source locations and syntax highlighting are mostly managed automatically in the macroexpander rather than something every macro must deal with (except for the macros that do something unusual with them).
Welcome back, conanite! I was coincidentally just thinking about you yesterday when I ran across your bug report at http://arclanguage.org/item?id=10485. Too bad that bug is still open in both Arc 3.1 and Anarki. I think I will try to fix it now that I've spotted it.