Ballerina's design point is to be a language with semantically equivalent text and graphic syntaxes. Its not a "visual language" really .. its a language with alternative syntaxes, one text and one graphic.
That approach eliminates the "hit-the-wall" phenomenon of visual languages. And as other commenters have said, a lot of the graphical view is useful to understand overall structure and less to write lots of code. However, parallel code is much better visualized graphically as sequence diagrams are dead simple to grok.
In terms of speed of the current Composer .. still WIP. Help is welcome :).
Maybe I am generalizing to hastily, but I absolutely despise the experience. In theory it sounds like a nice concept, in practice it tends to make trivial tasks exceedingly complicated[1]. And what would be a screen of code is several screens full of a block diagram. It is possible to zoom out, but text gets unreadable fairly quickly.
[1] To be fair, I think that is probably more of SharePoint problem, whose complexity would be hilarious if I did not have to deal with it.
Terry Gilliam has made some great movies (although I found Tideland too intense to watch). This one is now on the top of my to-watch list.
What I've seen is that while novices fairly quickly ramp up and get productive generating basic CRUD apps rapidly, they also rapidly hit a wall in two ways:
1. It can be hard or cumbersome to express more complex logic 2. The drag and drop interface often leads people to -assume- what the runtime will do.
Right now, I'm leaning toward feeling that visualization should be a tool to understand the _behavior_ of what one has written, but not necessarily the thing one manipulates to express a program. Ballerina seems to be this, so I'm excited there!
That would essentially generalise to "creating visual code", only now it would use the keyboard instead of the mouse.