>I don't think that's a usage of high level abstraction I'm familiar with The 'primitives' you are presented with are generally at a lot higher level of abstra

>I don't think that's a usage of high level abstraction I'm familiar with The 'primitives' you are presented with are generally at a lot higher level of abstraction in a visual language ('join' node vs '+'). Obviously you can build any level of abstraction using these primitives. >The geometry node editor in Blender has tons of hidden state - what are the inputs to your program, what are the outputs, how is it applied, etc I'm not overly familar with Blender. But aren't the inputs and outputs shown as connections? if so, they aren't hidden in the same way they are in code. >There's still syntax, it's just visual syntax. You don't have to remember the name of the function, you usually just have to drag it from a list of functions and there is no list of arguments to remember either. >I don't think there's anything stopping a visual programming language from offering functions, looping, and recursion. Both are possible in principal. >Most visual programming languages are purely data flow, but I think a control flow graph programming language would be very good at this. Trying to mix the two in one environment sounds like a recipe for a lot of additional complexity. >Another advantage of visual programming languages is you don't need to come up with names in order to reuse values Good point. >That said, there's no need to force these to be mutually exclusive. Indeed. Most visual programming environments include scripting nodes, to get the best of both worlds.