3 ms·

I think the whole concept is meh. Can you create visual builing blocks that are transformable to an AST? yeah, thats no problem for a given fixed set of bloc

I think the whole concept is meh. Can you create visual builing blocks that are transformable to an AST? yeah, thats no problem for a given fixed set of blocks. Can vsual blocks be as communicative as written language/syntax for much more open set problem spaces? Yeah as long as you don't want to make that AST, or yeah as long as you hand code the AST map to grow the set manually, but at what point do these visual representations fail to convey clearly the topic? There is a reason why you have textbooks in school and not a stack of photos. written language is much better suited to convey deep and complex information. Sometimes both together can convey a complex idea better than one in a silo, however without the text to convey what is trying to be shown in the image the complexities of the content in the image are severely limited. Code is written language, and just happens to be various forms of specialized language we use to convey these open ended concepts. Visuals just can't be as communicative. So I firmly believe that visual blocks are relegated to small sets of problem space and not these open ended sets of problems.

dkersten 7y ago
> There is a reason why you have textbooks in school and not a stack of photos. written language is much better suited to convey deep and complex information. There's also a reason why many of the best textbooks contain diagrams, images, charts and illustrations. Text is, in my own personal opinion, not the best way to convey deep and complex information of all types and sometimes its not best in isolation. Also, some people can learn through pure text and other people are more visual and find it much easier to understand things when stated visually. Personally, I find I often think in boxes and lines (relationships between things, I guess) so need pen and paper at hand when I need to think through a complex programming issue before I can turn into into textual code. > So I firmly believe that visual blocks are relegated to small sets of problem space and not these open ended sets of problems. Meh. I've written some open ended code in Max/MSP and I found it to be a really pleasant and productive experience. Sadly (at the time, at least), Max was too limited in features to really take it further (at the time it didn't have any support for data structures other than a few built in ones, I see that it now does, dunno if I just missed it or if its newer; also, no unit testing support was a big problem), but none of its limitations are limitations of visual languages, just of that particular implementation (which, to be fair, was never intended to be a general purpose language). Some things really are better suited to text, of course (mathematical formulas certainly), but the best visual languages let you use text for those. And annotate things with text as you wish. > visuals just can't be as communicative. I guess I'm a visual thinker, because I completely disagree. Sure, visuals alone are bad at communicating, but its never an all or nothing either or thing. I often find complex issues with just text extremely difficult to get my head around, but a nice diagram can make it trivial. "A picture is worth a thousand words" and all that.
- lioeters 7y ago
  I'm with you that pure text can be limiting as a medium for thinking and communication, and that using a wider range of visual expression like diagrams and illustrations can dramatically enhance understanding. No visual programming environment I've seen compares to the expressivity of writing code - but I also consider myself a visual thinker, and I believe there's still a lot of potential for imaginative rethinking of what it means to code. Text is just a subset of visual communication, and there's no reason why we need to limit ourselves to what can be typed - maybe we could include dynamic interactive symbols as new "words", or program by visually constructing diagrams that include code.. The sweetspot seems to me, visual languages that also let you use code.
  - dkersten 7y ago
    The ideal would be a language which has a non-ambiguous mapping between both textual and visual, so that you can freely switch between them as you wish, but I’ve never seen such a thing that was satisfactory and haven’t been able to come up with something myself. Having a visual AST or flowchart version of an otherwise textual language just doesn’t do it for me. Failing that, maybe a hybrid thing that lets me do mathematical code and pure algorithmic work textually, but to do all of the higher level architecture and coordination, asynchronous code and stream processing visually. Personally, I really enjoyed my experience with Max/MSP, I found it quite liberating in many ways and much (but definitely not all) of it suited my way of thinking closely enough that I could bypass the pen-and-paper to figure out complex things. I also really liked not having to name things (until I wanted to, at least) which I found made experimenting with ideas, before they were solid enough to put names to things, was also quite interesting.
    - 0815test 7y ago
      A "non ambiguous mapping", in the typical case, would be way too complex on the visual side, and way too trivial on the textual side. I.e. it would be used, by and large, either for unreadable spaghetti visuals or for high-level, almost trivial descriptions, the sorts which we routinely sketch on whiteboards anyway. Actually it's sort of nice to generate these sketches from code/textual syntax, but that's basically a sort of literate programming, and this is where its utility ends. There are visual syntaxes that are genuinely useful, but really as an aid to reasoning more than anything - so we're not that far from the "literate programming/documentation" case. I include the sorts of diagrams we routinely use, e.g. in category theory (commutative diagrams, string diagrams etc.) under those. > but to do all of the higher level architecture and coordination, asynchronous code and stream processing visually. Thing is, you'll still want to enter all that stuff as text - not by fiddling with a frickin' mouse. And the authoritative version of that code should be plain text as well - the system should be smart enough to cope with outside edits and do the visual formatting and layout itself if needed.

dkersten 7y ago

> There is a reason why you have textbooks in school and not a stack of photos. written language is much better suited to convey deep and complex information. There's also a reason why many of the best textbooks contain diagrams, images, charts and illustrations. Text is, in my own personal opinion, not the best way to convey deep and complex information of all types and sometimes its not best in isolation. Also, some people can learn through pure text and other people are more visual and find it much easier to understand things when stated visually. Personally, I find I often think in boxes and lines (relationships between things, I guess) so need pen and paper at hand when I need to think through a complex programming issue before I can turn into into textual code. > So I firmly believe that visual blocks are relegated to small sets of problem space and not these open ended sets of problems. Meh. I've written some open ended code in Max/MSP and I found it to be a really pleasant and productive experience. Sadly (at the time, at least), Max was too limited in features to really take it further (at the time it didn't have any support for data structures other than a few built in ones, I see that it now does, dunno if I just missed it or if its newer; also, no unit testing support was a big problem), but none of its limitations are limitations of visual languages, just of that particular implementation (which, to be fair, was never intended to be a general purpose language). Some things really are better suited to text, of course (mathematical formulas certainly), but the best visual languages let you use text for those. And annotate things with text as you wish. > visuals just can't be as communicative. I guess I'm a visual thinker, because I completely disagree. Sure, visuals alone are bad at communicating, but its never an all or nothing either or thing. I often find complex issues with just text extremely difficult to get my head around, but a nice diagram can make it trivial. "A picture is worth a thousand words" and all that.

lioeters 7y ago
I'm with you that pure text can be limiting as a medium for thinking and communication, and that using a wider range of visual expression like diagrams and illustrations can dramatically enhance understanding. No visual programming environment I've seen compares to the expressivity of writing code - but I also consider myself a visual thinker, and I believe there's still a lot of potential for imaginative rethinking of what it means to code. Text is just a subset of visual communication, and there's no reason why we need to limit ourselves to what can be typed - maybe we could include dynamic interactive symbols as new "words", or program by visually constructing diagrams that include code.. The sweetspot seems to me, visual languages that also let you use code.
- dkersten 7y ago
  The ideal would be a language which has a non-ambiguous mapping between both textual and visual, so that you can freely switch between them as you wish, but I’ve never seen such a thing that was satisfactory and haven’t been able to come up with something myself. Having a visual AST or flowchart version of an otherwise textual language just doesn’t do it for me. Failing that, maybe a hybrid thing that lets me do mathematical code and pure algorithmic work textually, but to do all of the higher level architecture and coordination, asynchronous code and stream processing visually. Personally, I really enjoyed my experience with Max/MSP, I found it quite liberating in many ways and much (but definitely not all) of it suited my way of thinking closely enough that I could bypass the pen-and-paper to figure out complex things. I also really liked not having to name things (until I wanted to, at least) which I found made experimenting with ideas, before they were solid enough to put names to things, was also quite interesting.
  - 0815test 7y ago
    A "non ambiguous mapping", in the typical case, would be way too complex on the visual side, and way too trivial on the textual side. I.e. it would be used, by and large, either for unreadable spaghetti visuals or for high-level, almost trivial descriptions, the sorts which we routinely sketch on whiteboards anyway. Actually it's sort of nice to generate these sketches from code/textual syntax, but that's basically a sort of literate programming, and this is where its utility ends. There are visual syntaxes that are genuinely useful, but really as an aid to reasoning more than anything - so we're not that far from the "literate programming/documentation" case. I include the sorts of diagrams we routinely use, e.g. in category theory (commutative diagrams, string diagrams etc.) under those. > but to do all of the higher level architecture and coordination, asynchronous code and stream processing visually. Thing is, you'll still want to enter all that stuff as text - not by fiddling with a frickin' mouse. And the authoritative version of that code should be plain text as well - the system should be smart enough to cope with outside edits and do the visual formatting and layout itself if needed.