> the problems I have with visual programming are The problems you have with LabVIEW are. This seems LabVIEW specific, not visual programming specific. Let me

> the problems I have with visual programming are 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 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.