4 ms·

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

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
> the authoritative version of that code should be plain text as well This is why I said the ideal would be a non ambiguous mapping: so that the text and visual code is equal and you can convert between them as you please. Unfortunately, this dream is unlikely. > Thing is, you’ll still want to enter all that stuff as text Why, though? I’m a very keyboard-centric computer user. I use tiling window managers, keyboard-centric editors (vim & spacemacs) and generally have my setup such that I rarely need to use the mouse. But I don’t see the value of needing this input to be through text. My experience with Max and Synthmaker showed me that using the mouse can be quick, easy and efficient. I spent a few months working with Max and having to use the mouse did not bother me as much as I thought it would. In fact, it didn’t bother me at all. I also dream of having this visual system on an ipad (because I’m wholly unsatisfied with the existing ipad programming tools, which are typically too text centric for a touchscreen) and would like to be able to use the touchscreen to draw my boxes and lines.
- 0815test 7y ago
  I do think that the "iPad" (tablet compute in general) is the very best case for "visual" interfaces to programming, yes. Although even then, you would have to find some way to keep spaghettification under check! It might also be that the best case there is more of something FORTH-like (albeit with types and other convenience features we do expect these days): minimize syntax, while making the most use of what's ultimately a rather limited input bandwidth.
  - dkersten 7y ago
    You make a good point about other syntaxes like FORTH-likes. That's an interesting concept that I hadn't considered! (Note, for a more "modern" take on FORTH, check out Factor[1]) As for spaghettification, I honestly don't see visual languages any different from textual languages in this respect. Yes, most visual code you see in the wild is horribly spaghettified, but the bulk of this code is also written by non-programmers who never learned software engineering principles (DRY, abstractions, proper naming, factoring, etc etc) and textual code written by the same class of people, in my personal experience, is just as spaghettified. Sometimes worse, even, because I can't put my finger on a line and trace it, I literally have to text search and mentally trace where named things connect. PS: Even though I don't quite agree with you, I appreciate the discussion! This is how ideas that may eventually lead to a workable solution are formed :) [1] https://factorcode.org/ https://factorcode.org/
    - lioeters 7y ago
      On spaghettification (great word, it's like a constant fight against entropy): I see a parallel between visual/codeless programming and domain-specific languages (esp. of "low code" category). As the user/application reaches a certain level of advanced usage, visual/low-code representations tend to turn into a big ball of spaghetti. As you pointed out, the reason I think has much to do with how the user is not familiar with programming concepts and organizing logic. On the other hand, I imagine it's possible to have a language/IDE that encourages good program organization naturally and intuitively, to guide and support managing complexity.. Well, this topic is deep and endlessly fascinating. Contrary to the originally posted article and its call of "doom", I'm more hopeful that the field of software development will continue to explore new and creative approaches.

dkersten 7y ago

> the authoritative version of that code should be plain text as well This is why I said the ideal would be a non ambiguous mapping: so that the text and visual code is equal and you can convert between them as you please. Unfortunately, this dream is unlikely. > Thing is, you’ll still want to enter all that stuff as text Why, though? I’m a very keyboard-centric computer user. I use tiling window managers, keyboard-centric editors (vim & spacemacs) and generally have my setup such that I rarely need to use the mouse. But I don’t see the value of needing this input to be through text. My experience with Max and Synthmaker showed me that using the mouse can be quick, easy and efficient. I spent a few months working with Max and having to use the mouse did not bother me as much as I thought it would. In fact, it didn’t bother me at all. I also dream of having this visual system on an ipad (because I’m wholly unsatisfied with the existing ipad programming tools, which are typically too text centric for a touchscreen) and would like to be able to use the touchscreen to draw my boxes and lines.

0815test 7y ago
I do think that the "iPad" (tablet compute in general) is the very best case for "visual" interfaces to programming, yes. Although even then, you would have to find some way to keep spaghettification under check! It might also be that the best case there is more of something FORTH-like (albeit with types and other convenience features we do expect these days): minimize syntax, while making the most use of what's ultimately a rather limited input bandwidth.
- dkersten 7y ago
  You make a good point about other syntaxes like FORTH-likes. That's an interesting concept that I hadn't considered! (Note, for a more "modern" take on FORTH, check out Factor[1]) As for spaghettification, I honestly don't see visual languages any different from textual languages in this respect. Yes, most visual code you see in the wild is horribly spaghettified, but the bulk of this code is also written by non-programmers who never learned software engineering principles (DRY, abstractions, proper naming, factoring, etc etc) and textual code written by the same class of people, in my personal experience, is just as spaghettified. Sometimes worse, even, because I can't put my finger on a line and trace it, I literally have to text search and mentally trace where named things connect. PS: Even though I don't quite agree with you, I appreciate the discussion! This is how ideas that may eventually lead to a workable solution are formed :) [1] https://factorcode.org/ https://factorcode.org/
  - lioeters 7y ago
    On spaghettification (great word, it's like a constant fight against entropy): I see a parallel between visual/codeless programming and domain-specific languages (esp. of "low code" category). As the user/application reaches a certain level of advanced usage, visual/low-code representations tend to turn into a big ball of spaghetti. As you pointed out, the reason I think has much to do with how the user is not familiar with programming concepts and organizing logic. On the other hand, I imagine it's possible to have a language/IDE that encourages good program organization naturally and intuitively, to guide and support managing complexity.. Well, this topic is deep and endlessly fascinating. Contrary to the originally posted article and its call of "doom", I'm more hopeful that the field of software development will continue to explore new and creative approaches.