Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Are visual program control flow diagrams and languages which support that used for larger serious programs? Why not? They seem like a nice overview of the code.

In the thread What software programming languages were used by the Soviet Union's space program? a visual language is mentioned (Drakon) and I wondered why such approaches aren't used more often?

Is there nothing a visual control flow representation (I don't mean class diagrams etc.) which are 1-to-1 with code can help compared to typing in letters in an editor?

share|improve this question
Define "serious". – user1249 Jun 11 '12 at 8:49
By "serious" I mean common software as opposed to interconnecting some predefined data transformations for image or sound modification. – Gerenuk Jun 11 '12 at 8:57
What is the actual question here? Are you asking about tools to generate code by drag and drop, tools to visualise control flow (but which don't allow modifying it), both, or something else? – Peter Taylor Jun 11 '12 at 12:18
@Peter: Tools which also generate some code - or where you can visually edit the control flow. Obviously not by drag and drop, but some more advanced method. Editor code folding is the most basic attempt. Now why not represent if/else by separate blocks next to each other? Why not visualize function calls, by showing the called functions next to it? How far in the direction of visual can you go while still being efficient? – Gerenuk Jun 11 '12 at 15:53
Checkout: – gsscoder Jun 11 '12 at 19:27

10 Answers 10

up vote 7 down vote accepted

I'm actually working on a visual programming language called "PIDEF" (Programmable Interconnected Data & Execution Flow) for commercial use.The target group is in the area of casual programmers that want to set up process control with low or medium complexity in a high level language.

From my experience, visual programming is great for high level stuff. Implementing quicksort from scratch would be no fun, but if there is a block that sorts a list for you, it doesn't matter much. So it really depends on what functions the language has on-board already. If there is some block that already does what you want, "writing" a program is (arguably) easier than in a line-based language. If there's not, it really depends on what primitives you have available to build what's missing.

Regarding the "overview" of the code, I'd say that visual programming requires even more care to keep the program logic readable. In PIDEF, there's no line routing (yet), so the connections between function blocks are straight lines, sometimes going through other blocks. In a non-trivial script, it gets messy real quick if the programmer doesn't sort the blocks in a sensible way. Even with line-routing and automatic layout algorithms, I'd wager that after ten, maybe twenty blocks on the screen with complex connections between them, the "overview advantage" is greatly diminished.

share|improve this answer

LabVIEW is a visual programming platform for controlling data acquisition, instrument control, industrial automation, machine vision etc. instruments from National Instruments. It's widely used in various industrial and academic research applications. It's certainly one of the pioneers in the field: the first version of LabVIEW was published in 1986, for Apple Macintosh.

Somehow it makes lots of sense: buy NI hardware, and it works right out of the box. The hardware instruments are abstracted as boxes that have inputs / outputs. You draw line from A/D converter to visual voltage meter display, and see the voltage in the meter. You generate signal and drive it to D/A converter. The textual programmer hasn't even fired up the API documentation when the graphical programmer is already done - in simple, elementary cases.

The pain begins when the application grows beyond the trivial. The nice graphical view doesn't help in battling the usual challenges of software complexity. Instead, it becomes literally spaghetti really soon.

share|improve this answer
LabVIEW is often used for engineering tests because it is quick to get simple logic running by non-developers. – M. Dudley Jun 11 '12 at 11:58
I've worked with huge LabVIEW applications (>1000vis/files in a porject); it does actually have really good architecture and structuring concepts - the problem is that it's very easy to get started with it, and few bother to learn anything more complex than a state machine, and just extend their "Hello World" to gigantic, horrifying piles of spaghetti. LabVIEW works with git and svn, has unit testing frameworks, is object oriented (if you want it to be), beautifully parallel.. – Birgit P. Oct 14 '12 at 12:29

One of the main argument against Visual Programming is the amount of information visible per "screen", meaning how much info on the program you can get without having to scroll. There is a comment made by Peter Deutsch, which is know as the Deutsch Limit :

Well, this is all fine and well, but the problem with visual programming languages is that you can't have more than 50 visual primitives on the screen at the same time. How are you going to write an operating system?

Of course one could argue that, first, this limit also exist with textual programming languages (I mean, you can't have that much lines of codes on a screen).

Also about "serious" software, I can mention Virtools, a french software started around 1993 IIRC, which used Visual Programming to create video Games and Virtual Reality Experiences. Although Virtools is not up to date anymore, it managed to create quite complex experiences.

Another point is that Visual programming can only be used as a high level language, as lower level algorithm require almost always complex formulas. It's easier to make mathematical computation using text symbols.

share|improve this answer
Textual programming languages use lots of compact syntactic constructs. For the most part they are essentially 1D languages that lean on our natural language processing capabilities and our years of training in reading and writing. 2D languages can't build on this prior knowledge, so it's much harder for them to develop a compact, highly expressive syntax without becoming hard to learn. – reinierpost Jun 11 '12 at 8:22

Other things against Visual Development are:-

  • Change Control -- what you commit to CVS/GIT/Mercurial is some probably an unreadable piece of XML. All those wonderful tools for listing differences, merging changes etc. become useless.

  • Static Analysis -- all the standard stuff you do for impact analysis such as searching for all usages of a method become absurdly difficult.

  • Portability and tool versions. Every heavily graphical environment I have encountered has this problem. The models are ultra sensitive to Version and environmental changes so what looks fine on your workstation looks like garbage when imported into my workstation.

share|improve this answer
very good points, especially n.1 – UncleZeiv Jun 11 '12 at 16:47

visual control flow representation which are 1-to-1 with code

There exist are such visual representations like Nassi-Shneiderman diagrams or flowcharts. However, since those diagrams are typically on the same level of abstraction like the code (at least since the invention of high level languages), they don't bring much benefit, neither for the writer of a program, nor for the reader, nor for the tools like interpreter or compiler which has to process such kind of program. And for the writer of a program, it just takes longer not just to enter the program, but also make some nice looking diagram from it (and if someone tells you there exist automatic diagram tools: I have never seen such a tool which was helpful for writing something like a >1000 LOC program).

Diagrams are most helpful (I tend to say only helpful) if they are on a higher level of abstraction than your code. Class diagrams are typically on a slightly higher level, depending how much you put into them, that's why they are are helpful when done correctly. Data flow diagrams are really helpful in software modeling, since they often provide a very good level of abstraction. Too bad the designers of UML missed that point when they decided to leave them out of UML.

share|improve this answer

Few answers say that in visual programming complexity is a problem, because diagram becomes unreadable.

It's of course problem, but the rules are the same as in textual programming: good project should be divided into files, classes, modules etc. Big program written in one function would also be unreadable.

So in visual programming you also have to divide program into particular diagrams to make it understandable and easy to maintain. Good visual language and tool are obviously necessary to do it in proper way.

share|improve this answer

One of the problems with VPLs in general (IMO) is that unlike textual programming languages, the VPL is greatly interlocked with the editor of the language. You may have created a very cool VPL, but if your editor sucks the language is not useful. This is very different from textual language where the users can choose their own editors (even vi!) and the compiler really doesn't care.

Another problem is that designing a VPL is a lot harder that designing a textual one. If you look at the most popular programming languages that exist today (C, Java, C#, JavaScript, Ruby, etc...), they are pretty similar, having the same basic constructs with small syntactic changes. But for languages that use the same paradigms, there is not much of a difference. On the other side, nobody is sure how loops should be represented visually, and this is actually one of the most complex problems in VPLs.

Last (but not least), while we are visual animals, there is still a lot of research to be done on how we understand visual elements. If one element of the language is on top of the other, what does it mean? what if one element is inside the other? what if they are connected with a line? You can give a set of semantics to each one of these cases, but if they are against the automatic way your mind would interpret it, you get Cognitive Dissonance and it will be a lot harder for you to understand the diagram. And since most VPLs are designed by programmers and not UX experts, most languages are simply too difficult to understand. And this is probably the reason why they are not widely used.

share|improve this answer

I think the problem has to do with verboseness needed to represent complex algorithm. Earlier programming languages were usually translated from mathematical model of solving problems. And these tended to look at an overall way of solving problems from simple to complex. And inertia probably kept them as written language instead of a visual.

share|improve this answer

(1) About Visual Tools

Its depends on the visual tool, and the developers.

I've work with some tasks that can be done by programming, but, can be very tedious, and, by using visual tools, people can cut development time shorter.

If you use visual tools in your project, be sure, everything you do, can be done programatically.

O.R.M. code generators are a good example of a visual tool, for something, that can be "coded by hand", but, its helpful to have a visual tool.

(2) About your project

Does, your project going to be visual related, have a visual interface, web, windows ?

You may require a visual tool.

Or, back-end, S.Q.L. programming, web services, COM, Shared Libraries ?

(3) About your developers

Something, that many people forget, and affect this question, its that not all developers are the same.

There are many developers who are very "textual" and "does not play well with visual tools".

There its the opposite, developers which mind or brain, its very "visual" oriented, and have trouble working with pure code.


You may want to check the previous points, to see how does applky to your question, and get to an appropiate answer for your case. Cheers.

share|improve this answer

Was just thinking of another use case that I'm facing every day.

Integration applications (message flows) are often created by graphical programming.

I'm thinking of Microsoft Biztalk, IBM WebSphere Message Broker, Mule ESB etc.

These applications are very specific and the gain by using graphical representation is that they represent a flow of a message that is convenient to visualize as connected nodes. However, to achieve complex logic, even in these applications, you have to invoke java/c#/XSLT/(E)SQL code.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.