True Visual Programming

eberta writes "We are still stuck with text programming for the most part. I can think of only a few truly visual programming environments like LabView and none are really mainstream for application development. Being recently unemployed and having ample spare time, I have started a pet project to work on my own version, GIPSpin (Graphical Interface Programming System). With multithreading becoming an increasing issue in software development, I'm wondering why hasn't there been more focus on visual programming. I see so much possibility of making coding easier and handling threading issues semi-automatically by allowing the user to graphically guide the auto-threading AI. Right now it seems the industry is focused on figuring out how to get just small chunks of code auto-threaded either through hardware or compiler technology, with longer term solutions like OpenMP still text based environments."

Comments

Another implementation.

[saintlupus]

Here's a visual programming environment called SIVIL that one of the professors here at Canisius has been working on for a while.

http://www-cs.canisius.edu/~meyer/VP/home.html

--saint

Graphical Programming is Inefficient

[ActionAL]

Believe me we use an old Honeywell system at work called MeasureX which uses graphical programming. EVERYTHING IS BLOCKS AND LINES CONNECTING EACH OTHER. It is the most inefficent way to read code possible. The human brain can read text code insanely faster than trying to decipher a huge picture with tons of blocks and lines strewn everywhere with complex connections and pipes from page to page. It is the most horrible thing I have ever seen. And if you have one missing connection or pipe, goodness good luck trying to debug it.

Different tools for different purposes

[booch]

I think the parent poster has a lot of important points. But one thing I haven't seen mentioned in this entire thread is that each type of programming/thinking/communicating has its place. While visual layout of complex program logic is not a good way to program, a written procedural language is probably not the best way to create a GUI. We should be using descriptive languages (whether visual or text) for GUIs and such.

For example, a typical how-to book is mostly text, but it also includes diagrams of how to put things together, and pictures of the completed project. All of these are essential to the book. Another good example is teaching. Teachers employ multiple methods of teaching, as different people learn differently, and different topics lend themselves to different styles. Some people learn best by doing; others by watching; and others by reading.

I think the right thing to do regarding visual programming is to relegate it to where it works best. I suspect that this would be mostly related to things that are already visual -- i.e. graphical (GUI) layouts, etc. I think it's also useful to be able to visually represent program code "in the large" in a graphical manner, to see the inter-relations, but I don't think manipulating that type of graph is useful.

I remember the old NeXT Interface Builder. You would take components, and connect them together. You'd have to write code if you were doing anything complex, but you could set up the GUI, including callback functions, visually. I think it's still around in Mac OS X. Things like GLADE work similarly. I'd like to see these types of tools used more.

Re:Problems with 'Visual Programming'

[kentquirk]

Back in '93 or so I was the UI designer on a visual programming version of VB that Lotus developed (and later sold to Revelation software). We had "links" between UI elements and code snippets so that you could build basic VB apps without actually breaking out the text editor. It worked pretty well as an accelerator for basic application development, but eventually you ended up writing text-based code. It just saved you time getting started.

I liked the idea so much I went out and built a game around it -- MindRover (http://www.mindrover.com/) where players constructed robots using purely visual programming techniques (no text-based code at all). It worked, and it was great for a game, but it made for a cumbersome development process. It's hard to look at an image and see everything you need to see.

Visual programming is cool and fun. It makes the learning curve for programming a little flatter, and it can be a nice way to prototype stuff and get the early versions of an application running. But using it to build apps that are more than toys is a much bigger challenge, and I haven't seen anyone yet who has done it effectively. The original poster's research looks an awful lot like a demo I saw at MIT Media Lab about 5 years ago. IMO, it exposes a bit too much of the syntax of conditionals and things in the visual UI. It's not far enough from textual programming to be helpful.