2. Spaghetti code: Read the Dijkstra's paper on Goto, and mentally replace 'goto' with 'line'.

3. Text labels: Many graphical languages have lots of text labels in the display.

4. Limits: There is a human visual limit of about 50 items in a graphical picture, unless there is a underlying graphical semantic context such as geography or time series.

5. Too Big: Once the diagram is larger that one screen, navigation and comprehension become exponentially more complicated.

6. Graphical API: Not clear what is the graphical equivalent to modules, namespaces, packages, etc. How would you package reusable code and make an API available?

During the 1970's, I spent years working on CAD tools, including logic schematic entry and IC layout programs. This was using graphical tablets in the pre mouse era. Even simple 8 bit microprocessors were too complex to draw schematics on a display, and barely possible to layout by hand on a display. I note that today logic design is using text languages such as Veralog, and layout is mostly automated.

Any visual programming language can be serialized to and deserialized from a linear format, which can easily be subject to diff.

It should be fairly straightforward from that to also build a visual interpretation of the diff of the serialized forms (e.g., an animation of the transformation from the original to the new form.)

Visual vs. semantic changes is only an issue if the language admits multiple visual representations that are structurally equivalent rather than (e.g.) accepting different inputs and reducing them to a canonical representation. But even if you allow that, you should be able to use canonicalization of that type "behind the scenes" to generate diffs which are comprehensive or which only identify semantically-significant changes.

> 2. Spaghetti code: Read the Dijkstra's paper on Goto, and mentally replace 'goto' with 'line'.

As in text language, using block structure rather than arbitrary gotos addresses this. There is no reason a visual language can't be block structured. (If you are concerned about procedure/function-calls-as-lines rather than gotos-as-lines, there's no reason that calls need to be lines; callables can be shapes, and calls can simply be inclusion of the shape in the procedure being drawn.)

> 4. Limits: There is a human visual limit of about 50 items in a graphical picture, unless there is a underlying graphical semantic context such as geography or time series.

There are similar limits in other domains, which is one of the reasons for structured decomposition of code in general. I don't see why this would apply less to visual code.

> 6. Graphical API: Not clear what is the graphical equivalent to modules, namespaces, packages, etc. How would you package reusable code and make an API available?

In general, names are shapes -- I don't see why that would be any different for names of namespaces vs. names of individual items within a namespace. Sure, how you depict either "opening" a namespace or accessing a name from it in a qualified way would be something a graphical language with namespaces would have to decide.

I worked on a visual dataflow language for complex ETL between databases some time ago. My experience with that was I would rather write Scheme directly (which is basically what the pretty directed graphs turned into). Mostly out of familiarity, but I did find the textual representation was denser and so faster to work with once familiar with it; maybe it's all about having the right level of abstraction for the task at hand.

I suspect a successful general purpose visual programming language would have to have some really powerful abstractions for parallelism and concurrency to take off in place of languages that already exist. You also have to remember the problems people have had integrating Smalltalk's image-based persistence with non-Smalltalk parts of a system, and avoid that kind of insularity.

There are ways to carefully clean it up and keep it logical - but once you get into all of that, you might as well have been working in text.

Look at Printed Circuit Boards (PCBs) for hardware. For complex hardware logic, you often end up with multi-layer boards. The boards carry higher complexity and cost, but designers use them because two-dimensions is simply not enough for the interconnects.

Here are some challenges that need to be overcome: 1/ I agree that the inertia of history is against visual systems. There's a lot of catch-up required to reach parity. 2/ People get comfortable and are often reluctant to adopt something new, especially when it's a big change. 3/ Text files provide a simple program representation, a format that's standard across languages. I don't know of a comparable data format that might work across visual languages. E.g., we need something that supports good diffs in a language-agnostic way. 4/ There's perception that a visual language needs to be programmed with a mouse, and that it would cater to beginners but not experts. I see no reason why I shouldn't manipulate visual elements with keyboard shortcuts and will use anything that helps me get the job done better. 5/ There's a perception that programming in a visual language will be slower, but I don't think that need be the case.

When I write software using a powerful IDE I often feel pretty far removed from the experience of writing a text file. There's a sensation of taking abstractions out of my head and putting them into the computer, with the text-file being a rather ancillary element in the programming / runtime environment as a whole. My feeling is that the text file has come to be limiting and I'd love to see other formats emerge.

When graphic programming languages provide an entirely new and better way of making what we today call a computer do what we want, then they'll catch on. In the current environment, I don't think visual languages can compete with the expressiveness and flexibility of text.

Plus I'd probably suffer from shoulder RSI injuries from pushing the mouse around.

Looking at the third advantage, finding logic errors, it is still a bit of a stretch since many pure logic errors can be caught by compilers and tests and the typical pernicious logical errors are related to modeling the domain rather than endless loops or dead code paths.

Finally, not only are words are a really compact way of communicating but the Turing Machine model of computation is based upon alphabets and input strings and thus text is closer to the metal than pictures.

That said, Drakon is an interesting language developed for the Russian space program that leverages graphics in conjunction with text.

http://sage.com.ua/en.shtml?e6l0

Check out Max/MSP, Pure Data, and Apple's Quartz Composer.

https://en.wikipedia.org/wiki/Max_(software)

https://en.wikipedia.org/wiki/Pure_Data

https://en.wikipedia.org/wiki/Quartz_Composer

https://en.wikipedia.org/wiki/Visual_programming_language

I'd argue that some of the Microsoft stuff involving XAML and Blend and database tools could be considered visual programming, but I can see the other side of the argument.

In highly domain specific areas VPLs are actually widely used. Blender 3D modelling tool is basically a graphical way of editing and visualising the underlying data structures. Now if you replace abstract syntax graph you can see the similarity.

wrt @RNeff's comment, AutoDesk Revit is a great example of how it might be possible to create a more general purpose programming language. What sets Revit apart from Verilog & VHDL is that it presents the user with context specific editors by which to set the parameters for the many different components of the designed building.

Starcraft has one thing that modern graphical editors don't have: reactivity. State is synchronized behind the scenes between client and server (who is also a client). You "program" predominately in response to events, which can be initiated by the game itself, player action or by another function call.

Reactivity, which is programming in response to events, in my opinion, will lead to the first useful non-notepad editors.

The three advantages that you cite are not.

1) there is no less fighting with syntax when you use a graphical syntax than when you use a textual syntax. Now we can agree that a lot of textual programming languages have horrible syntax. I would advise you to try Common Lisp or Scheme. The use of S-exps (Symbolic Expressions) in those languages is a recognition that the syntax doesn't matter, and therefore the uniform and systematic use of the forms: (operator argument argument) for all the language elements is a big simplification at the lexical level. However, there still remain a syntactic element, an essential one, where you have to know that eg. the IF operator takes three arguments, a test, and then-expression and an else-expression, in that order:

   (IF (= 1 a) 
     (print (quote one))
     (return (quote done)))

2) It is not easier for beginners to pick up. Only to children who don't know how to read yet. But then, one may argue that they ought to learn reading and writing before trying to write programs. In anycase, at this age, you would rather use objects than graphics, to let children play, programming "robots" by putting operation blocs into slots in a specific order.

3) Ok, it's your opinion, but graphical forms do not make it easier to find logic errors. They may help in getting an impression, and forming a mental image. But it would be dangerous to rely on them in a rigorous reflection about the program properties, just like it is bad to use the graphical diagrams to reason in Euclidian geometry. As goes the saying, geometry is the art of making correct reasoning using wrong graphics. Actually, you can do all geoemetry purely in textual and logical form, without ever using graphics, because the geometrical objects are abstract objects, and the graphical forms are only coarse approximations of the geometrical concepts. Similarly, the graphical forms of algorithms and programs, are but coarse approximations of the program logic, which is better described using text.

There's also another inconvenient of the graphical forms: they lack abstraction. You can zoom in and zoom out, and sometimes, you can even hide subcomponents in closed boxes, into which you can navigate graphically to discover the inside diagram, but by definition an abstraction is naming a concept. And text is better for names, if only because of the combinatorials. Take a standard human, and try to determine how many gestures, or how many different ideograms he is able to create and later recognize to identify different concepts. Similarly, count the number of words or names he is able to create and use to identify those concepts.

Finally, there's the question of the complexity of the tools required to manipulate graphics (and animations at that, if you want to manipulate sophisticated graphic views), vs. the tools required to deal with text, with a clear advantage for the later.

And let's not forget, at the beginning was the Verb, not the Image, and it's the Verb who was Creator.

That said, graphical forms can still be useful in the context of programming, notably when you want to explain some concepts. You can use various kind of diagrams, to present facets of software (cf. eg. UML), and other free-form diagrams. But either you have some formalized graphical syntax like UML, and therefore you bring the complexity of reading and writing correct meaningful diagrams, or you are left with ambiguity usually found with graphical forms, and you can only use as an illustration to some textual description.

You could also compare a program drawn in Piet vs. the same written in any textual programming languages :-) Can you tell what this program does: http://www.dangermouse.net/esoteric/piet/Piet_hello_big.png http://www.dangermouse.net/esoteric/piet.html And what about this one: http://rosettacode.org/wiki/Hello_world/Text#Modula-2

That said, if you read Asimov's Foundation serie, you may remember the room where the psychohistorian mathematicians worked, where mathematical formulae were displayed on all the walls of the room and where they could explore and manipulate them graphically with gestures and other input. I'd agree that it is possible that eventually we have sufficiently smart AI programs to be able to write programs and other mathematical proofs in graphical or such dynamical modifiable forms with simple and easy input (ie. with the system basically guessing what transformation or addition you mean from your grunting and waving). But I don't see that practical before AI is achieved.