3 ms·

I have another theory why it doesn't scale. Visual programming is very spatial. This may seem helpful at first but actually it gets in the way of development pr

I have another theory why it doesn't scale. Visual programming is very spatial. This may seem helpful at first but actually it gets in the way of development process. Developing isn't just writing (drawing) new code. It is iterative process of juggling many pieces of functionality so they work well together. When you have to refactor some logic, suddenly blocks move to different places, and their relative positions change. Whenever related blocks change relative orientation, your internal model for navigation becomes obsolete. Human brain is not used to this and it creates discomfort and frustration. Traditional programming done with text files in which functions have 1D organization. Because 1D has less spatial relations (just above and below), code reorganization is cognitively easier. It's easier to find good place for piece of code and it's easier to remember where it lives. I think a truly usable visual programming tool should not allow users to place blocks at arbitrary positions, but should automatically (and predictably) arrange pieces on screen. Structural text editors (for example [1]) are step in right direction, while connected blocks seem to me like a dead end. Another problem is structuring the code - the 2D space is simply too crowded to represent layers of abstractions in flattened way. The hyperbolic plane would help here [2]. Not every bit of whole design can be shown at once (this would result in information overload), but editor could show what is in focus as well as one or two levels of context. As to success of existing visual languages, I'd argue that they are all targeted at non-technical people and they all run within sandbox environment developed with traditional text code. Why aren't their creators dog-fooding? My own answer to this is that existing visual languages cannot support the necessary amount of complexity. [1] https://git.sr.ht/~technomancy/anarres https://git.sr.ht/~technomancy/anarres [2] https://www.youtube.com/watch?v=8bhq08BQLDs https://www.youtube.com/watch?v=8bhq08BQLDs

CyberDildonics 6y ago
> Visual programming is very spatial. I think this is worth stating, but I think it really means that expressions take up much more space. This can be confronted from two directions. First, don't use nodes and noodles for expressions, because it doesn't help clarity and hurts density. Use nodes at a higher level instead of searching for a silver bullet. Second, of course one flat work space does not scale. Node based tools already have ways of grouping nodes as well as making groups that can be instanced instead of duplicated. > connected blocks seem to me like a dead end. Connected blocks of any sort mirror how programs work in the first place. Automatic organization is typically pretty helpful though. > Another problem is structuring the code - the 2D space is simply too crowded to represent layers of abstractions in flattened way. The hyperbolic plane would help here [2]. I'm not sure what this means, but I'm guessing it is also solved by grouping nodes and making components by groups that can be instanced. > As to success of existing visual languages, I'd argue that they are all targeted at non-technical people and they all run within sandbox environment developed with traditional text code. Why aren't their creators dog-fooding? My own answer to this is that existing visual languages cannot support the necessary amount of complexity. This is definitely not true. There are many extremely technical people using visual languages because they are huge speed ups in productivity - more interactive and less error prone by a huge degree. Shader writers use nodes instead of text all the time. Lots of tools transitioned from being text based to being graphs. The difference is that they are domain specific and not general purpose programming languages. It is the general purpose nut that hasn't been cracked.

CyberDildonics 6y ago

> Visual programming is very spatial. I think this is worth stating, but I think it really means that expressions take up much more space. This can be confronted from two directions. First, don't use nodes and noodles for expressions, because it doesn't help clarity and hurts density. Use nodes at a higher level instead of searching for a silver bullet. Second, of course one flat work space does not scale. Node based tools already have ways of grouping nodes as well as making groups that can be instanced instead of duplicated. > connected blocks seem to me like a dead end. Connected blocks of any sort mirror how programs work in the first place. Automatic organization is typically pretty helpful though. > Another problem is structuring the code - the 2D space is simply too crowded to represent layers of abstractions in flattened way. The hyperbolic plane would help here [2]. I'm not sure what this means, but I'm guessing it is also solved by grouping nodes and making components by groups that can be instanced. > As to success of existing visual languages, I'd argue that they are all targeted at non-technical people and they all run within sandbox environment developed with traditional text code. Why aren't their creators dog-fooding? My own answer to this is that existing visual languages cannot support the necessary amount of complexity. This is definitely not true. There are many extremely technical people using visual languages because they are huge speed ups in productivity - more interactive and less error prone by a huge degree. Shader writers use nodes instead of text all the time. Lots of tools transitioned from being text based to being graphs. The difference is that they are domain specific and not general purpose programming languages. It is the general purpose nut that hasn't been cracked.