Visual programming for serious software

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

(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.

Summary

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.

Answer 10

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.