edit: Thinking about it a bit more, whats lacking in all the examples of visual programming I've seen is a clean way to build abstractions. It would take a while to learn to efficently read and style visual code just like it does with text based code. That I think i could get used to. The thing that I find alarming is the prospect of manipulating an ever growing graph.
Just like there are best practices with code there are best practices with how you organise this kind of graph. you can usually save a subnetwork into a single node that has a clear input and output. ie, double clicking on a node will take you to another network with a clearly defined purpose. Im obviously better at these graphs than I am a programmer, but it seems to me that doing it this way actually encourages encapsulation and abstraction.
Theres also some good stuff about these graphs that I think coders can miss out on. With a graph you can use the idea of space to organise things. Our brains have a natural ability to remember where things are in space. Its like organising things on your desk, I have a pencil here , my notepad here, books in the drawer, it feels very naturall to have things laid out in space, you remember where you put them. With a graph I know that all the stuff in the top right does one task, im outputting data out the bottom etc..
It works really well when you have clear input and output. Again Im not the best programmer but I think after using these graphs for years I instantly got what people are talking about when they are promoting functional programming. I think these networks have a place where you are creating operations to do on existing things.
Visual formats are great at some things, especially in expressing concrete concepts that are perceptible. They are just not great at abstraction, which forms the basis for most of our non-trivial programming tasks.
Functional programming is quite interesting because it is not based on our linguistic capabilities, but rather a very different form of mathematical abstraction. Incidentally, many people find OO easier to grock because it leverages our intrinsic language skills.
Dynamo has the notion of a "custom node." This is essentially a lambda. It is represented by a "nested" set of nodes, making up the function body.
There's a bunch more stuff going on there - including compiling nodes to a domain specific, associative language called DesignScript.
The problem is that language is great at metaphor, which is the basis of abstraction. For better or worse, language is based on words, and we have specialized hardware (in our brain) optimized for it. Until we evolve communication in an abstraction-dense format that isn't based on words, I don't think we'll be able to scale VPLs.
Animated GIFs, perhaps. :)
Sheet music, source code, mathematical equations, graphs, etc. are examples of tools we use make it easier to form mental models.
> It would take a while to learn to efficiently read and style visual code just like it does with text based code.
This is why domain specific VPLs work so well: because they allow people work within a mental model they are already familiar with.
That doesn't really get you towards end-users writing code but I'd find it pretty useful when trying to look at a complicated process.
what am I expected to do here?
On a serious note, there are some domain-specific programming tools in which visual approach works well. For example functional protocol testers (with SDL) or data acquisition (LabView and such).
The project is largely inspired by this one, whose original engine used a similar approach of compiling a visual program to Scheme: https://github.com/DynamoDS/Dynamo
