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.

Why are visual program control flow diagrams and diagrammatic languages, which are used to visualize programs not used to program those 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 else, than a visual control flow representation like class diagrams etc. which are 1-to-1 with code, something else instead of "typing in" letters in an editor?

share|improve this question

closed as too broad by gnat, Bart van Ingen Schenau, MichaelT Nov 18 at 20:14

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the 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

11 Answers 11

up vote 9 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

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
even worse, a lot of "visual" programming environments output binary files rather than text as the "sourcecode". Several go even further and have no concept of source and compiled code at all and can only produce some form of semi-compiled binary that's then fed into a runtime environment for execution (think how Java'd be if your IDE would produce class files rather than java source files). – jwenting Nov 18 at 16:13

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

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

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

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

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

I am a few years late, I am impressed by everybody's comments they show that you all have been reflecting about visual programming and in general what you say is true to a certain degree. The answer: Yes higher abstract programming languages will be used for serious application programming and visual programming language based software life cycle, VPL will be one if not the one higher abstracted language used.

Meaning software like CRM, ERP, Warehouse and others are written in a visual programming language

You mention a few good points regarding the VPL's extensibility, and general applicability. While I, personally, have a almost clear picture of what those are or should be we have to define these and other reference points and tools completely new for visual programming languages. Is a domain defined by a profession sales, warehouse worker or by an instance of software deployment, a software that services a part of an organisation, for example accounting billing and sales ?

If some one digs up the deutsch limit, by definition every language has a deutsch limit so why does that matter, ok one is relative more compact than the other at the display of information at one level.

Well and the views get cluttered with visual as well as text based languages after a certain point.

I think we should not try to measure one new language paradigm with the other, yes from machine code to assembler to C and on to Java, to use the same reference system there, is ok, all of them are text based, but to judge the visual programming language with the same guidelines as the text based once is a bit near sighted.

In short the answer is yes real software is and will be programmed in a much higher abstraction and visual is one of them. At least my work shows that. The different approach actually make programming more accessible and a bit faster.

We would like it to be 2 or even 10 times faster right :) ok we reach that, we still have to get through the acceptance of this approach amongst technical as well as non-technical professions !

share|improve this answer
my experience is that "visual programming" is constantly being hailed as "just around the corner" and that "it will replace writing code completely in just a few years" using tools that "allow analysts to compose the entire program so there's no more need for programmers". I've been hearing that constantly for over 20 years, if anything we're now further removed from that state than we were 20 years ago. – jwenting Nov 18 at 16:18
Well I sadly observe the same, when it comes to the wide spread announcements over the last decades, nevertheless I can tell you for sure, complete software is and will be programmed visually. The analyst, you mention, will have to program which will make him a programmer, using a new definition of programmer. A programmer who does not code, has to be able to think in programmatic terms, AND coding programmers are and will be needed more so in the future than now. We are further removed from the point of accepting visual programming because of the long tail of unfulfilled expectation. – C.Ott Nov 18 at 16:47
The biggest problem (quite apart from the serious limitations in what the systems can actually generate when it comes to business functionality) is that the generated stuff can't be created to conform to your corporate style without serious customisation that requires a lot of hand coding. And of course the generated software will perform poorly and be very hard to maintain. – jwenting Nov 20 at 15:56
Which systems are you talking about ? Any discussion about form over function or CPU cycles per transaction(at business level) is not so important as the question do you see that the overall system supported by custom software made in a different way, faster easier, at the speed of business, is beneficial ? I invite you and non professional programmers to have an open mind toward your team, your business and think if they can benefit from that approach. It is innovative and new based on the old vision. I am looking for constructive feedback and, I do not think that this question is too broad. – C.Ott Nov 20 at 17:34
any system. What's generated by such generators invariably needs customisation to work within the corporate landscape of an enterprise. While your mom and pop shop may accept their new ledger software having some generic look and feel, a multinational will require that it adopts their corporate standard for colours, logos, placement of fields and everything else. They'll also require it to have a specific way it communicates with external systems, and there will be many of them. – jwenting Nov 21 at 13:20

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