Hard agree. For me, it's the delegation of concerns that visual programming excels at.
I don't have to care how you're getting a random point in a sphere. Whatever algorithm you want to use works for me. And since you know which algorithms work better for which scenarios, you can put all of that delegation under the hood. All I have to know about is which node to use. And if something starts breaking, I know that it can't be my problem; it has to be a problem with the node's code and that domain professional can address it.
Of course, a good dev might say "That's just having a really good API", which is true! But once you have an API so good that you don't need to know any of its internals, you're essentially trying to write a graph using documents, which is kind of silly.
High-level servers are a great example (node servers, python servers, etc). There's not any utility in writing an expressJs server with text that isn't satisfied by writing it as a flow chart. Servers, at that level of abstraction, are so simple that all you really need to do is tell which keys go where, when. And that's most simply done by drawing boxes and arrows that all point to each other.
Put more starkly: there's no difference between writing `Lib.Physics.GetPointInSphere(param1, param2, param3)` and linking a `GetPointInSphere` node to `param`s 1, 2, and 3. So I think that if you're in a domain that is already at that level of abstraction, visual programming is a fantastic way to go. And if you're not already at that level of abstraction, there's value in getting there (even though it's probably going to require fracturing/modularizing existing concepts).
I don't have to care how you're getting a random point in a sphere. Whatever algorithm you want to use works for me. And since you know which algorithms work better for which scenarios, you can put all of that delegation under the hood. All I have to know about is which node to use. And if something starts breaking, I know that it can't be my problem; it has to be a problem with the node's code and that domain professional can address it.
Of course, a good dev might say "That's just having a really good API", which is true! But once you have an API so good that you don't need to know any of its internals, you're essentially trying to write a graph using documents, which is kind of silly. High-level servers are a great example (node servers, python servers, etc). There's not any utility in writing an expressJs server with text that isn't satisfied by writing it as a flow chart. Servers, at that level of abstraction, are so simple that all you really need to do is tell which keys go where, when. And that's most simply done by drawing boxes and arrows that all point to each other.
Put more starkly: there's no difference between writing `Lib.Physics.GetPointInSphere(param1, param2, param3)` and linking a `GetPointInSphere` node to `param`s 1, 2, and 3. So I think that if you're in a domain that is already at that level of abstraction, visual programming is a fantastic way to go. And if you're not already at that level of abstraction, there's value in getting there (even though it's probably going to require fracturing/modularizing existing concepts).