3 ms·

> 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

> 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.

xg15 11y ago
> 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.
- paulhodge 11y ago
  > 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.
  - wdanilo 11y ago
    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 :)

xg15 11y ago

> 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.

paulhodge 11y ago
> 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.
- wdanilo 11y ago
  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 :)