For what it's worth, mathematicians work on paper so they aren't constrained by anything, but they still use textual nested syntax instead of visual dataflow graphs.
Frege's notation is another example, although it was a bit idiosyncratic, but its legacy very much lives in proof theory.
And then there are string diagrams, proof nets, ...
Do you know anybody doing maths who could say "well I've never felt the need to use a figure in my life"?
Yes exactly. And if you look at the common methods for how knowledge is represented, in mathematics or any field really, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures.
An image can be extremely helpful and illustrative if appropriate. But almost nowhere do you see people communicate primarily with images.
Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment; it'll only be successful in niches.
I'm not quite sure how humans could communicate primarily with images, at least until neural interfaces are in widespread use... I would argue that, yes, we communicate primarily with text, because we have the innate skill - speech - to do so efficiently and we have no equivalent skill for images. This doesn't tell anything about how knowledge would be best expressed in theory.
> And if you look at the common methods for how knowledge is represented, in [...] any field, it's very roughly around 80% knowledge as text and 20% graphs/diagrams/figures.
Sources, please. But even assuming this is true, this would leave 20% which are better represented visually. And I believe it's a worthwhile goal to integrate visualisations for those 20%. An integration like this seems possible with Luna's approach of offering both, a text and a visual representation.
> Text is king. I think if the programming environment doesn't embrace text as the primary input method, then it's not really good as a general-purpose environment
I agree with you that it's a good idea to have some textual representation - If for nothing else so you can use existing tools. But that seems to be exactly what Luna is going for, if I understand the site correctly.
I don't see why text has to be the primary input method.
Yeah, I'm withholding judgement on Luna specifically, until we can see it in action. Their model could be a good one, it all depends on whether they treat the text representation as a first class citizen or not.
1) Standard AST - one that is a common and extendible syntax representation. Both the textual code as well as visual graphs are able to translate to and from this AST model. To be most precise - both representations are just some kind plug-ins (with some funny type-level-safety built-in) over this AST representation, so they are both first class citizens and they are completely equal to each other.
2) Core AST - a desugared, type-checked, minimal lambda calculus language, that is used to perform all sort of optimizations before next steps towards generating the target code (assembly / js).
We treat the graphical interface exactly the same way, never favoriting any representation over the other. If you would like to develop another one, like natural language input, you have just to provide methods for translating it to and from AST and our infrastructure delivers everything you need to translate it to and from visual or textual one.
I hope this spots a light over the internal design of Luna :)
It's true that there are some visual notations in mathematics, but they tend to be the exception rather than the rule, and where they are used it's a mixed system most of the time. Frege's notation was half symbolic half visual, and the visual part of it didn't catch on except for the horizontal line. The rest of it got "symbolified". I don't think that's a coincidence. Actually the most commonly used half visual half symbolic notation in mathematics is the commutative diagram. I suspect that over time even the use of those may decrease in favour of symbolic type theory notation.
I do think some sprinkling of visual notation is useful, also in programming, but representing expression trees as dataflow graphs? That has been tried many times and it hasn't been successful, nor is it likely to be in the future. I don't think flat text has any future though. A program has structure and is not best represented as an array of characters. Symbols and nested syntax are here to stay however. Humans just deal better with nesting and symbolic references than with a forest of lines and arrows.