> Difficulty with large programs or large data. [...] too little will fit on the screen Solved by the ability to pan and zoom. Node graph tools in professional

> Difficulty with large programs or large data. [...] too little will fit on the screen Solved by the ability to pan and zoom. Node graph tools in professional visual effects environments can grow to >20,000 nodes in a document, especially given that nodes can be nested in groups or cross-included from other documents. > Need for automatic layout. [...] For example, generating an optimal layout of graphs and trees is NP-Complete [95]. Doesn't need to be absolutely optimal to make the problem go away; making something that helps the user enough that they don't have to think about it is completely tractable. Many professional node graph tools don't do any automatic layout at all and let the user handle it; which while less than perfect, doesn't stop the tools from being incredibly powerful. > Lack of formal specification. Currently, there is no formal way to describe a Visual Language. First, a formal specification is not necessary in order to build something useful. Second, if you really need a formal specification, then write/invent one. There is nothing about visual systems that makes them less possible to specify than any other software system. > Tremendous difficulty in building editors and environments. [...] These editors are hard to create [...] the language designer must create a system for display [...] which usually requires low-level graphics programming. So... do that stuff? What about that work is more difficult than the other parts of writing a compiler; or any other piece of complex software? Maybe this was more of a big deal in 1989, but basically all software today is based on a visual UI, so the complaint that the need for a UI makes visual languages intractable is... pretty ridiculous now. None of this would be harder than, say, writing a simple video game. > Lack of evidence of their worth. There are not many Visual Languages that would be generally agreed are "successful" "Nothing good exists yet, so nothing good is possible" doesn't hold water for me. > Metrics might include learning time, execution speed, retention, etc. From my experience in visual effects, non-coders can pick up a node graph tool very quickly and get very creative/inventive with nodes— but the moment they have to fall back to writing a script, they struggle or don't even try. It seems abundantly clear to me that node graphs are far easier to learn (but can be just as powerful) as writing with a machine grammar. I also did an image processing development project in a node graph tool that took about 4 days of experimentation to get to patentable IP. If I had to do the same project in Python or C++, it would have taken weeks or months, if I was even able to solve the problem at all without the fluidity and responsiveness of the node based editor. So even for "serious developers", a good node-based editor can multiply speed by a factor of 10. > Poor representations. Many visual representations are simply not very good. Can't argue there— but the solution is to make one that is good. :) > Lack of Portability of Programs. [...] Graphical languages require special software to view and edit ...Like basically all other file formats in the universe. :) It is not 1989 anymore, and it's time to fix this stuff.