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.
Fantastic advice.
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.
1. Thank you! I figured arc could have gone a lot further with special-syntax, by making it configurable inside arc code.
2. this "open source" has had only two eyeballs on it so far ... attacks welcome :)
3. The execution stack is entirely plagiarised from rainbow so it should not be hard to re-implement continuations in the same manner ... the need hasn't arisen yet though ...
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.
I guess the quote idea came from me thinking that the strings were being evaluated. My untrained mind thought "strings evaluate to themselves", but apparently not. So I used the single quote to prevent evaluation.
