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

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