Visual programming is really hard to debug. Just as people tend to give the advice to limit a procedure/method to one page, because you start to lose control. Y

Visual programming is really hard to debug. Just as people tend to give the advice to limit a procedure/method to one page, because you start to lose control. You just can keep up with so much. Where does this line goes in? You just don't know. Collaboration is nearly impossible. Opening projects from others will be much worse than looking at pure code. Also it is too verbose. The 'functions' take away a lot of screen estate (this is most obvious for mathematical stuff). If you start on just a bit more than something you could have achieved in 50 LoC, it tends to get really messy. VP lacks referencing as well. At least most of those envs I know. Declared a variable? Too bad, you have to connect this node to everywhere you need it. Sigh. Reusing of components is possible, and for some envs it is implemented, but mostly just per file, not in general, e.g. you can make a custom component inside one project, and if you edit it, all instances get updated, but you can't save that as a standalone component you can XREF in other files/projects, which makes it hard to make a custom library of functions. But it depends on the industry. As others already mentioned, the more an industry is led by visuals in the first place, the more common it is to actually utilize Visual Programming (or rather Scripting), also it's quite useful in real time contexts – which is the place where the strengths are. The CG industry is one of those, but also architecture and design in general (think of McNeel's Rhinoceros with Grasshopper, THE most used visual scripting environment used as of today, especially in a professional setting). Conclusion: VP has its merits and is used extensively, just maybe not the places you expected/hoped for.