It is very exciting to post the vision. It gets many views and spreads far and wide.
It is much less exciting to hear about the issues the vision encountered. And they do encounter visions.
Humans can only hold so many ideas in their head at the same time, commonly expressed as somewhere around 7 or so. Our programming systems are intrinsically and deeply bent around this, trying to limit the necessary context for any given bit of code to fit within this constraint. We don't even see this because it is the water we swim in.
So when we imagine coding, we can't hardly help but imagine manipulating like 7 things. And 7 things fits on the screen great, and 7 things fits in our minds great, and it makes a great demo. What is much harder is realizing just how often we work with things that are much larger than that, and, intrinsically so.
A good solid example that is larger than that, but still in the realm of things we can understand, is an HTTP request. A few dozen elements, each of which may have a few "things" in it, amounting to one or two hundred things. You've probably seen visual representations of such, with the header names on the left and the values on the right. Already any attempt at making this visual and live is straining, but it can be done.
And then you have a database table with, let's say, 150 columns and several million rows, and the visual metaphor is dead.
We have too many things like the latter. We encounter them all the time. The reason for this is not sloppiness in programming or a failure of vision, but the fact that our 7 +/- 2 values we can hold in our mind is really really small and simply inadequate to address the universe. We encounter things all the time that are very challenging to fit into that box. Any programming metaphor that requires that everything fit into that sized box is a non-starter. A total non-starter.
This is ultimately why "visual programming" in general has failed and will always fail.
If we could as easily hold, say, 50 things in our mind, we would have so many more options. We burn so many of our 7 +/- 2 values just holding references to the place we need to go to go get more values if we need them, e.g., dedicating a slot just to the fact we have a database connection. Further slots needed to handle what we're querying from that database, etc. If we had more registers we could spend a lot less time just managing the registers, even if we would still ultimately hit limits. But this stuff slams into a complexity wall with us humans so, soooooo quickly after the first pretty demos.
This is why you see a steady stream of such demos, which look awesome, and then they go nowhere, because you can't hook it up to a web server, or a non-trivial database, or just about any code you can imagine, really. Games are already an "easy mode" for this demo, most things are not games or graphical displays, and they fall over quickly too because again as soon as it's non-trivial in the game world it doesn't work anymore.
And this makes me sad. But it also makes me sad to see people jousting with the same windmill over and over. So my usual followup here is, if you are interested in trying yourself, I strongly suggest looking at the historical efforts, and at least coming up with a theory as to why whatever it is you are thinking about will do better and will solve the problems I lay out here. Maybe there is a solution. I can't guarantee there isn't. And precisely because I know it is hard, if you succeed, I will be that much more impressed. But I do want you to know it is a hard problem. The common characterization of it as being easy and obvious and my god how could everyone else be so stupid as to miss this is frankly offensive. We are not collectively stupid. We are not collectively idiots. We do what we do for good reasons. If you do not start from that understanding, if you don't understand the good reasons why the current textual paradigm is dominant, you're doomed from the beginning.
It is very exciting to post the vision. It gets many views and spreads far and wide.
It is much less exciting to hear about the issues the vision encountered. And they do encounter visions.
Humans can only hold so many ideas in their head at the same time, commonly expressed as somewhere around 7 or so. Our programming systems are intrinsically and deeply bent around this, trying to limit the necessary context for any given bit of code to fit within this constraint. We don't even see this because it is the water we swim in.
So when we imagine coding, we can't hardly help but imagine manipulating like 7 things. And 7 things fits on the screen great, and 7 things fits in our minds great, and it makes a great demo. What is much harder is realizing just how often we work with things that are much larger than that, and, intrinsically so.
A good solid example that is larger than that, but still in the realm of things we can understand, is an HTTP request. A few dozen elements, each of which may have a few "things" in it, amounting to one or two hundred things. You've probably seen visual representations of such, with the header names on the left and the values on the right. Already any attempt at making this visual and live is straining, but it can be done.
And then you have a database table with, let's say, 150 columns and several million rows, and the visual metaphor is dead.
We have too many things like the latter. We encounter them all the time. The reason for this is not sloppiness in programming or a failure of vision, but the fact that our 7 +/- 2 values we can hold in our mind is really really small and simply inadequate to address the universe. We encounter things all the time that are very challenging to fit into that box. Any programming metaphor that requires that everything fit into that sized box is a non-starter. A total non-starter.
This is ultimately why "visual programming" in general has failed and will always fail.
If we could as easily hold, say, 50 things in our mind, we would have so many more options. We burn so many of our 7 +/- 2 values just holding references to the place we need to go to go get more values if we need them, e.g., dedicating a slot just to the fact we have a database connection. Further slots needed to handle what we're querying from that database, etc. If we had more registers we could spend a lot less time just managing the registers, even if we would still ultimately hit limits. But this stuff slams into a complexity wall with us humans so, soooooo quickly after the first pretty demos.
This is why you see a steady stream of such demos, which look awesome, and then they go nowhere, because you can't hook it up to a web server, or a non-trivial database, or just about any code you can imagine, really. Games are already an "easy mode" for this demo, most things are not games or graphical displays, and they fall over quickly too because again as soon as it's non-trivial in the game world it doesn't work anymore.
And this makes me sad. But it also makes me sad to see people jousting with the same windmill over and over. So my usual followup here is, if you are interested in trying yourself, I strongly suggest looking at the historical efforts, and at least coming up with a theory as to why whatever it is you are thinking about will do better and will solve the problems I lay out here. Maybe there is a solution. I can't guarantee there isn't. And precisely because I know it is hard, if you succeed, I will be that much more impressed. But I do want you to know it is a hard problem. The common characterization of it as being easy and obvious and my god how could everyone else be so stupid as to miss this is frankly offensive. We are not collectively stupid. We are not collectively idiots. We do what we do for good reasons. If you do not start from that understanding, if you don't understand the good reasons why the current textual paradigm is dominant, you're doomed from the beginning.