> 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.
> 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
I really like this description of a possible language / IDE, where textual code is the "canonical" representation of the program, with visual layers of interaction to manipulate higher abstractions.
At the bottom, I still think it would be an abstract syntax tree, with textual and visual "views" into the program. As I've got VS Code open in front of me, a few examples come to mind:
- Minimap: a condensed visual overview and navigation of code structure
- Color picker: hover on a color value in code, and select from a color wheel, adjust transparency, with preview
- Type annotations: hover on a variable, function, class instance to see a tooltip showing their type definitions, reference link to source
These are all various ways to represent and interact with the same underlying code, and I imagine many more possibilities exist to extend the "visual programming" aspect.
A quick idea as an example, there could be a mode/view to see the entire program and its modules/dependency tree visually, move classes around, rename/refactor methods..
Whenever "codeless software" and similar topics come up, it always reminds me to re-study the work of Douglas Englebart, Ted Nelson, Alan Kay, Seymour Papert, Bret Victor [0].
> I still think it would be an abstract syntax tree
I agree. What I meant with my comment was that the visual syntax shouldn't simply be a direct visual representation of the syntax tree, because if that's all it is, I'd rather just write in a Lisp with a graphical tree visualisation generator.
I definitely like the idea of having many possible views of the code, where a traditional textual language is just one of those.
> a few examples come to mind
That sounds quite similar to what LightTable attempted to achieve. Its nice and useful and I want to see more of it, but I don't think its far enough, at least for a discussion on visual languages ;)
> it always reminds me to re-study the work of Douglas Englebart, Ted Nelson, Alan Kay, Seymour Papert, Bret Victor
Absolutely! They've been a major influence on my own line of thinking on the subject.
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.
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 :)
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.
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.
I can't imagine this being possible with two humans looking at the same visual display/image and aligning on its "true meaning" let a lone an automated system doing it. Reduce the problem down to a fixed set of visuals with mapped meanings to AST and you can get there but then you are a vastly limited "language" of functions and that explodes into a horrible and complex visual tree to get any non trivial complexity described.
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.