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.
That's a completely false analogy. We rely on text to represent what's best written as text. When you want to speak of a specific automaton or graph, you'll give a figure, unless the mathematical structure is really big (infinite maybe) and thus best described intentionally.
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"?
> We rely on text to represent what's best written as text.
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.
> But almost nowhere do you see people communicate primarily with images.
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.
> But that seems to be exactly what Luna is going for, if I understand the site correctly.
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.
Paul we do treat BOTH text and visual graphs as first class citizens. Luna's compiler is all about AST modification. In fact Luna provides few different AST models, the most important are:
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 :)
I agree that for describing a specific graph, drawing it is sometimes the best way. Most of the time an automaton or graph is a mathematical object under study. The notation used to study graphs and automatons and prove things about them is symbolic. Saying that maths notation is visual because a mathematician might draw a diagram to illustrate their proof is like saying that programming is already visual because a programmer might draw a diagram to illustrate their program.
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.
Ironically one of the first languages of formal logic used a visual syntax [1] but only parts of it remain in use: as ordinary textual operators (like the turnstile ⊢ or negation ¬).
