Fog Creek Software
Discussion Board

Coding, visually?

What do you folks think of coding visually (graphically) instead of the traditional text-based approach?

Visual languages like IBM Data Explorer and A/W Maya's MEL are great success stories.

I am not talking about stuff like UML that captures high-level design, but something at the code level. Isn't it easier to 'read' code in a 2-dimensional graph than a 1-dimensional text document? At least one do not have to mentally create a relationship diagram since it is all captured and presented in front of your eyes.

What are your experiences and thoughts?

Rex Guo
Saturday, December 22, 2001

I have no experience in such a thing but .. seems too weird ! I think nothing will replace a plain code that is almost the last "spec" of what CPU is doing .. Visual reading of code may be fun, but not visual coding, IMHO.

Evgeny Goldin
Saturday, December 22, 2001

You can still call a visual piece of code the 'last spec', depending on how much (if any) abstraction happened when going from text to graphics. I was referring to a 1-to-1 mapping, at the lowest level, for example:


int add(int a, int b); // declaration
int c = add(1,2);      // usage


A person new to programming will have a hard time figuring out the C version, since the syntax is not part of his/her knowledge, but I think he/she will understand the diagram version immediately.

Rex Guo
Saturday, December 22, 2001

Joel, please remove the useless feature of stripping extra white-spaces. In many cases, it is intentional and you just destroyed my beautiful ASCII diagram!

Rex Guo
Saturday, December 22, 2001

Anyone interested in a truly "through and through" visual coding environment might want to check out Toontalk, a 3D programming environment created to teach programming concepts to kids.  I've used it with great success in some volunteer work with 10 and 11 year olds.

Toontalk carries the visual paradigm further than any environment I can imagine.  You "program" by manipulating objects in a 3D world with your 3D arm and hand.  You create programs by training robots to create and/or manipulate objects in the world.

It's very difficult to describe with words.  The programming language has no syntax at all, at least not a verbal one.  All you have are objects that you train robots to manipulate.  Robots get trained by "remembering" a series of actions you lead them through.  The environment has 3D metaphors for everything in a text programming language:  robots correspond to methods; a box with one hole where it can hold things is a variable; a box with multiple holes is an array, etc. 

If after that description you think it sounds like a child's toy, then you should take a look at it before you make a snap judgment.  Although it's created for kids, you can create some pretty sophisticated apps in it; although right now it's tailored more for creating games than for business apps.

Even though you program in a 3D world, the apps you create can be 2d apps if you want.  These would have a rectangular panel object with robots embedded into it doing the manipulating.  All you would see with the running program would be the objects on the flat panel, e.g. text and numbers.  Unless you were to flip it over, in which case you could "watch" the robots doing their work.

It's a mind-blowing piece of software.  Not of much practical use for creating business or system apps, but that may be because it's focussed on enabling kids to create games, not on serious stuff.

If you have any interest in visual programming environments at all, you'd enjoy reading more about it and downloading a demo at .  Look closely at it and do a few things with it; it really will blow your mind.

Herbert Sitz
Saturday, December 22, 2001

There's a few realities that make visual coding a little more difficult than it ought to be.

First of all, we've all learned to program in text, which is a skill in itself.  Learning to read diagrams that are packed with information isn't always fun, especially when you grew up with another technique.

(If you want to see what I mean, take a look at the screenshot on this page:
This is just a simple gcd.  Now picture trying to debug that.  Now picture debugging a complex algorithm.  *Shudder*)

Secondly, you can get a lot more information on to a page in text than you can in pictures.

I find it interesting that early civilizations invented alphabets to convey information as a replacement to pictures and carvings.  Writing is a more accurate conveyor of information than the History of our Tribe as Carved on a Rock.  In light of this, I don't see that going back to a visual would necessarily be better.

Visual coding, however, could be serviceable in certain situations, e.g. editting a program on the class/module level.

Jim Barlow
Sunday, December 23, 2001


You presented some good arguments, but consider this:

1. For someone who is new to programming, or has the condition dyslexia (some known to be savants or even geniuses), the visual approach is certainly easier to learn. That's why we were taught flow charts and entiry relationship diagrams.

2. The Flipcode image you showed has very fine granularity. This has the effect of producing an overly complex diagram from a very simple underlying logic. I think visual programming is much more effective at a higher-level granularity, which is suitable for RAD. 'a picture is worth a thousand words', 'the big picture'.

3. As with all forms of communication, bad grammer/vocabulary can break the best 'languages'. Therefore the quality of a visual implementation largely depends on things like the choice of icons, flow of arrows, layout and routing. It also depends on whether there are any abstractions or transformations happening as well. Any form of communication can be intentionally obfuscated.

4. Visual programming IDEs are horribly primitive compared to text-based IDEs. Text-based IDEs have evolved to include many features that help navigate code and augment the coding process. Stuff like class wizards/viewers, auto-completion, call-trees, and recently .NET IDE's collapsable code blocks are all welcome examples. If the same effort went into creating a visual IDE, we could be looking at a revolution in RAD.

5. Here are some screenshots:

Rex Guo
Sunday, December 23, 2001

This is an interesting area, I have been working with some software called FormScape which applies a graphical programming environment to a specialist domain, output management in this case.

Rather than a flow chart style this program uses a tree view of an application with a number of objects you glue together to build an application.

It works quite well in terms of offering rapid development for many requirements although I always find myself stretching its capabilities too far, I keep wanting to drop into writing code which you can do.

I guess what it is really offering is advanced configuration or meta programming rather than an alternative to traditional languages like C++ or VB.

Tony Edgecombe
Sunday, December 23, 2001

Complications with "reading", editing, and debugging visual applications are things that have been discussed in the newsgroup for Toontalk, the visual environment I mentioned in an earlier message.

It's interesting, because with visual programming (at least with Toontalk), there is literally nothing to read.  To view a program (called a "computation") you really just have to watch it in action. 

Ken Kahn, the developer of Toontalk, is working hard  on developing different ways to make the viewing, editing, and debugging of Toontalk programs easier. 

One possible way to "read" a Toontalk program involves creating "snapshots" of the actions of a robot through time.  There's nothing to read, but you can see what the action in each shapshot frame is, and step backward or forward through the frames to "read" or edit the Robot's method.  Checking out these snapshot sequences for each robot is similar to stepping through lines of program text.

Issues of temporality seem to cause the the most difficulty for viewing and editing visual programs.  It's difficult to "see" how a program will act through time merely by looking at a single static picture.  It will take quite a bit of ingenuity to make it easier to read visual programs in this way, and may never be as easy as following the logical path through textual commands.

Herbert Sitz
Sunday, December 23, 2001

I've got limited experience with "visual" programming: Khorus, an image-processing app, and LabView, and lab-equipment controller.

Labview is very powerful, and makes many things very easy to do, and easy to read. But it can be cumbersome when writing mathematical procedures, or complex logic.

If you're interested in visual programming, find someone at a research university to show their LabView program.

David Fischer
Monday, December 24, 2001

I'm surprised it took so long for LabView to get mentioned... it is extensively used in industry and as I am all too aware, experienced LabView programmers are quite hard to find these days, demand is high. We have used it for years to create programs that automate the functional testing of electronic assemblies in a manufacturing environment, and are very dependent on it.

I'm a C/C++ programmer, so I find the graphical approach a little confusing, but have managed to get in and maintain LabView programs when necessary. The graphical presentation makes it fairly easy for a maintainer to grasp what is going on in the program. It's an inspiring sight to see an experienced LabView hand at work... it's a powerful and productive tool for its purpose.

What I don't like about it is the gigantic size of the compiled programs, and the difficulty of managing all of the dependencies (all those VI's... oh no! Error 7!) in a build. But running a program in debug mode is a joy.

Robert Cunnings
Monday, December 24, 2001

Visual communication has its place, as does symbolic (i.e. text). UML is a good example of this. There are some notations in UML that express design very well in a visual sense.

However, implementation is usually a place where visual communication is effective. The symbolic representation of code serves the developer and the machine ideally.

With respect to the argument about novice programmers, I do not find this sound. Although some concepts of programming are taught to novices in a visual manner, they are incomplete. The reason they form part of the curriculum is that teachers need to focus on specific elements of programming to make their points.

This does not mean that visual programming is more effective for novices to *program*, just more effective for novices to read about some elements of programming. For example, flow charts are not intuitive and do not communicate the behaviour of non-trivial systems that have state.

Reginald Braithwaite-Lee
Wednesday, December 26, 2001

I think in this context, 'visual' means a solid three dimensional representation rather than some symbolic notation method.

If you like, Lego for design (I've just spent two days with Lego building), much as envisaged in Microsofties. 

Peter Jackson (he of Structured Programming not Lord of the Rings), would no doubt flip over plugging his 5 types of units together, Looping, Sorting, Selection, Processing and  Reporting. 

Smalltalk developers could also get mileage out of it, though I think they'd prefer to use balloons somehow or possibly the Hogwarts Express and Owls carrying messages. 

As always the C++ crowd would have a harder problem trying to bang their blocks together.  Its the interface guys, the interface, all your blocks have to plug together!

Simon Lucy
Wednesday, December 26, 2001

I think the old 1-dimensional textual approach where you use a sequence of strings to represent a sequence of logical events in a source program is about to go through the window.

Visual systems that are well designed and logically sound and can abstract a lot of the features found in the old tectual programming systems are far more productive tools for programmers and can be very useful for learning the essential features of programming languages very quickly. I am not realy refering to UML base systems. They tend to be a bit too out-of-reach for the average programmer. I am generally talking about systems that uses straight program flowcharts such as visio, source2Flowchart or more interestedly: LogicCoder.

LogicCoder is an interested system I am looking at because it is unique in that it actually writes a source program from a flowchart design. In addition, it emphasise a structured design and code writing approach. It is suppose to do the reverse of writing a program from a flowchart but I have not seen that yet.

It seems to me that in the near future programmers will not be able to get away with writing foolish programs that no one can understand. LogicCoder seems to be setting the stage at the moment by integrating Design, Code writing, Documentation and Maintenance of a software system.

Calbert McDonald
Monday, June 7, 2004

No discussion of this can possibly be complete
without mentioning Prograph ( Programming in Graphics )( and Sanscript ( a visual , dataflow programming language.

They are  mature and have been used for applications.

Sanscript has featured in DDJ and was used at one stage by Compaq for the Compaq Batch Scheduler.

Prograph has its own newsgroup. comp.lang.prograph
And has been used to create a variety of applications ( commercial ones too ).
See The Made With Prograph List:

The brainchild of Tomasz Pietrzykowski , it was a seminal work. Mac and Windows versions are available at

For a tiny (878K) quicktime home movie of Prograph in action, look here

Here is a quick tutorial

israel thomas
Tuesday, July 27, 2004

Khorus has been renamed visiquest.
This image gives an idea of its

israel thomas
Tuesday, July 27, 2004

*  Recent Topics

*  Fog Creek Home