Having worked with LabVIEW a fair amount, the problems I have with visual programming are:
1) takes up a lot of space
2) each subroutine (sub-VI) has a window (in the case of LabVIEW, two windows), so you rapidly get windows spewed all over your screen. Maybe they've improved that?
3) debugging is a pain. LabVIEW's trace is lovely if you have a simple mathematical function or something, but the animation is slow and it's not easy to check why the value at iteration 1582 is incorrect. Nor can you print anything out, so you end up putting an debugging array output on the front panel and scrolling through it.
4) debugging more than about three levels deep is painful: it's slow and you're constantly moving between windows as you step through, and there's no good way to figure out why the 20th value in the leaf node's array is wrong on the 15th iteration, and you still can't print anything, but you can't use an output array, either, because it's a sub-VI and it's going to take forever to step through 15 calls through the hierarchy.
5) It gets challenging to think of good icons for each subroutine
6) If you have any desire for aesthetics, you'll be spending lots of time moving wires around.
7) Heavy math is a pain visually (so you use the math node that has it's own mini-language, and then you're back to text)
as someone who's worked a lot with LabVIEW and automating some considerably old instruments...i hate it i hate it i hate it. I hate it with the fire of a thousand suns, most every paradigm I know is wrong in this bizarro-land willy-wonka very proprietary and very expensive IDE. Not a fan. Not worth the opportunity cost of not learning other languages that are useful in society. Its the school of thought it subscribes to, the way things are designed just makes zero sense. Learning something that makes you unlearn the right way to learn a way that only works with one company's MATLAB-priced software, is no fun at all.
Came here to mention space. I have tried to build "mobile" graphical programming. Looking at the factorial example at flowgrid.org, it should be easy to see how a one-liner takes up the whole screen...
The problems you have with LabVIEW are. This seems LabVIEW specific, not visual programming specific. Let me contrast your experience with LabVIEW to my experience with Max/MSP:
> takes up a lot of space
Yeah, but, my Max code only took up a bit more space than my C++ code ever did. Sure, I now use Clojure which is a lot denser, but I didn't find the space it took up to be a problem when I used Max. I did aggressively factor code into subroutines though.
> each subroutine has a window
Agreed, but I think there is room for experimentation here. Synthmaker/Flowstone has a visual map thing at the top where you can see the zoomed in/out (iirc) views and subroutines opened in the main window, which then navigated this map. That is, subroutines didn't open in new windows and the map let you quickly navigate up and down the abstractions. It worked well in my brief time with Synthmaker, so I could envision LabVIEW or Max do something similar.
> debugging is a pain
I found debugging in Max, where you add probes to connections and can see the data that flows through them, much nicer than debugging C++, Java or Python (three languages I've used extensively).
> debugging more than about three levels deep
The trace/probe window let me see all probes, no matter the depth, so I didn't have this problem.
> It gets challenging to think of good icons for each subroutine
Max used words, but I didn't have to give them names if I didn't yet know what they would do: I could write the code without subroutines to experiment, then select any areas I wanted to abstract (to simply or for DRY) and it would put it in a subroutine and then I could name it or not as I felt necessary.
> If you have any desire for aesthetics
I did, but I didn't find I spent too much more time than I o aligning text, maybe a little. I factored things into subroutines aggressively and generally just kept things aligned for nice straight lines.
> Heavy math is a pain visually
True, I agree with this point, except that I don't think using the math/expression node is a problem and that going back to text for that is a problem. Right tool for the job: visual for dataflow, text for math expressions. I thought it worked really well.
I'm not saying visual languages are perfect, but I do think that there is lots of room for improvements and just because someone has had a bad experience with one visual language, doesn't mean the whole paradigm has those problems. That's like trying Haskell and complaining that all textual languages are hard because thinking in monads was challenging.
For an interesting take of something I'd love to see explored more: https://vimeo.com/140738254 (Jonathon Edwards' Subtext demo), there are many ideas left to explore and not enough visual languages to explore them, compared to the many textual languages we see that try new ideas.
1) takes up a lot of space
2) each subroutine (sub-VI) has a window (in the case of LabVIEW, two windows), so you rapidly get windows spewed all over your screen. Maybe they've improved that?
3) debugging is a pain. LabVIEW's trace is lovely if you have a simple mathematical function or something, but the animation is slow and it's not easy to check why the value at iteration 1582 is incorrect. Nor can you print anything out, so you end up putting an debugging array output on the front panel and scrolling through it.
4) debugging more than about three levels deep is painful: it's slow and you're constantly moving between windows as you step through, and there's no good way to figure out why the 20th value in the leaf node's array is wrong on the 15th iteration, and you still can't print anything, but you can't use an output array, either, because it's a sub-VI and it's going to take forever to step through 15 calls through the hierarchy.
5) It gets challenging to think of good icons for each subroutine
6) If you have any desire for aesthetics, you'll be spending lots of time moving wires around.
7) Heavy math is a pain visually (so you use the math node that has it's own mini-language, and then you're back to text)