Filter Forge founder here, now working on a turing-complete functional visual programming language inspired mostly by Haskell: https://imgur.com/a/HkSgJ
Here's what I currently think on visual programming languages:
1. I see no place for imperative and non-pure functional languages in visual programming.
2. Pure functional languages can absolutely be implemented with visual syntax. This is just another form of representing a program. Instead of taking text as an input, the compiler / interpreter takes the node-based representation, which may or may not directly correspond to the AST. Here's an example of the same toy program in Haskell, Racket and our visual language: https://i.imgur.com/dsNJYyx.png
3. Visual languages shine on higher levels of abstraction. They work great in Filter Forge and similar systems, e.g. material / shader editors in 3D packages or game engines. However, I've never seen a visual language that remains usable and understandable on a lower level of abstraction.
4. Our civilization has settled on text as the lowest common denominator format of information exchange. We have accumulated an enormous amount of tools, infrastructure and software ecosystems built around text. Git, Slack, WWW, Copy / Paste, Ctrl/CMD + F, diff tools, IDEs, regexps, Unix pipes etc etc etc. A visual language will have to reinvent all these wheels.
5. Visual programs have no equivalent of line numbers for addressability. You can unambiguously refer to a location in a text program with just two numbers, line & column, but how do you do that in a visual program? "Uh, it's the red rectangular block with the blue output, to the left of the square green one. The connection you need is the second from the top."?
6. I see no way of quickly commenting out / deactivating a section of a visual program.
7. When you write a text program, you are compelled to give descriptive names to things like functions and variables. A visual program doesn't force you to do that. For example, in our language you connect function outputs to function inputs with graphical arrows, and named binds aren't necessary. In Haskell, however, if you don't want your program to look as a huge chain of function applications, you bind results of certain function to named 'variables', and the names tend to be human-friendly (well, at least in monomorphic functions). To sum up, visual languages lack built-in annotatability and don't compel programmers to annotate programs. Annotation feels extraneous, tacked-on.
8. I/O is hard. Sure, it can be done the Haskell way, but without some kind of monadic sugar (somehow adapted to a visual language) it would be absolutely unpalatable. Also, this would only work on visual languages that are capable of expressing a monad.
Although, I think your ui is too verbose. Main indicator, is, well, the size of "blocks of data", where text takes 4 times less space than visual representation. But there is also an information overload: text representation of `map` call has no indication of what kind of arguments it expects, it is implied by order of args and basically is just defined by language. I guess, visual analog of this code should follow the same trope: it should strip type annotations (which probably should be available VP IDE with a shortcut), and imply meaning of args (maybe with colors?)
Filter Forge is great. I was thinking on doing something similar and will definitely take inspiration on FF.
What will be the use of your next turing complete VPL ?
Here's what I currently think on visual programming languages:
1. I see no place for imperative and non-pure functional languages in visual programming.
2. Pure functional languages can absolutely be implemented with visual syntax. This is just another form of representing a program. Instead of taking text as an input, the compiler / interpreter takes the node-based representation, which may or may not directly correspond to the AST. Here's an example of the same toy program in Haskell, Racket and our visual language: https://i.imgur.com/dsNJYyx.png
3. Visual languages shine on higher levels of abstraction. They work great in Filter Forge and similar systems, e.g. material / shader editors in 3D packages or game engines. However, I've never seen a visual language that remains usable and understandable on a lower level of abstraction.
4. Our civilization has settled on text as the lowest common denominator format of information exchange. We have accumulated an enormous amount of tools, infrastructure and software ecosystems built around text. Git, Slack, WWW, Copy / Paste, Ctrl/CMD + F, diff tools, IDEs, regexps, Unix pipes etc etc etc. A visual language will have to reinvent all these wheels.
5. Visual programs have no equivalent of line numbers for addressability. You can unambiguously refer to a location in a text program with just two numbers, line & column, but how do you do that in a visual program? "Uh, it's the red rectangular block with the blue output, to the left of the square green one. The connection you need is the second from the top."?
6. I see no way of quickly commenting out / deactivating a section of a visual program.
7. When you write a text program, you are compelled to give descriptive names to things like functions and variables. A visual program doesn't force you to do that. For example, in our language you connect function outputs to function inputs with graphical arrows, and named binds aren't necessary. In Haskell, however, if you don't want your program to look as a huge chain of function applications, you bind results of certain function to named 'variables', and the names tend to be human-friendly (well, at least in monomorphic functions). To sum up, visual languages lack built-in annotatability and don't compel programmers to annotate programs. Annotation feels extraneous, tacked-on.
8. I/O is hard. Sure, it can be done the Haskell way, but without some kind of monadic sugar (somehow adapted to a visual language) it would be absolutely unpalatable. Also, this would only work on visual languages that are capable of expressing a monad.