Slashdot Mirror
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."
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
We do not think using a poor graphical representation of the Real World. Given this, text is the best way of representing stuff on a computer (except were graphics are explictally necessary).
Now, when we get realistic VR systems that actually feel like RL, this may be a different matter (although source code would have to be represented as text at some level as both computers and humans think one-dimensionally with strings of text or numbers).
At the moment all we have is slow 2D graphics on flickery, bright, flat screens. We have far too go.
Joe Llywelyn Griffith Blakesley
[This post is in the public domain (copyright-free) unless otherwise stated]
I used to write IVR applications, interactive voice response. They're the automated phone systems that everyone loves to hate.
While I had been doing it for ten years it never failed that when there was a regime change within the company some new high level manager would read an add in some random telephony journal and think he could magically reduce our IVR development time ten times over.
Yep, everytime it was one of those graphical languages. Look! Just connect the voice prompts to touch tone input nodes then uhm, magic.. and we're done!
At least in the products we were forced to try it never worked out that way. Any type of call flow the GUI developers didn't have in mind would be like pulling teeth. You'd have to work around the narrow vision they had. That defeats the purpose of it being simple or rapid.
Worse yet, there was no way to optimize anything. On an 800 line dead-head time costs money. If I'm trying to ask someone for a PIN so I can start billing them for the call I need to shave off every fraction of a second I can. After hundreds of thousands of calls those fractions add up! But since you have no low level control of anything you're completely at the mercy of the developers that wrote the language.
Then there's code re-use. I hadn't seen a package that let you easily create libraries. If a problem was found with a frequently used "drawing of code" you couldn't use any automated tools to find or fix it, you have to open each by hand and look. I hate things you can't grep on.
Anyhoo, UI editors are about as visual as I prefer to get. It's an interesting project and for some applications it might make sense. I haven't found one yet.
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.
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.
Software sucks. Open Source sucks less.
Squeak Smalltalk can do multiple cursors. Someone would have to do a bit of simple hackery for Windows/Linux to take two PS/2/usb mice and feed it to Squeak, or also there are some easier (but more expensive) ways to do it with two squeak processes. The usual use of two (or more) cursors in Squeak is for the remote access/collaboration software built in- you can have 5 people connected remotely, each with their own cursor with its own focus, as well as the person who is sat down in front of the computer. No problem, it's all there.
It may be a place to start playing if you're interested in that sort of thing.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
All human beings should try to learn before they die what they are running from, and to, and why. --James Thurber
Visual representations work better than textual representations for most technical things, but only if you choose the right visual representation.
Example of a good visual representation: music composition software with virtual modules/machines/synthesizer that you graphically plug together into a virtual "rack" of equipment for your song. Software like BuzzTracker or Psycle, which take this visual approach, are far more efficient to work in than the old textual interfaces provided by programs like ScreamTracker3 or Impulse Tracker.
Example of a pretty good, but still imperfect, visual representation: the desktop GUI. From within the GUI, you can accomplish just about everything you could possibly ever need to do with your computer. It's almost never necessary to pull up a command prompt to get something done, because the GUI provides an equivalent, more-understandable, typically more-efficient way to do it. Of course, there are still cases where the GUI provides a shitty, inefficient visual representation (or worse yet, no visual representation at all) and you do still have to resort to the command line to get something done, or to do it more efficiently. This just illustrates how choosing the right/optimal visual representation is the real challenge, and it also illustrates how it's an ongoing work-in-progress to pick the "optimal" visual representation.
Example of a bad visual representation: most visual programming models developed thus far. As others have pointed out, most visual programming models put together so far are too high-level to be realistic programming environments for real-world purposes. This doesn't mean that visual programming will never work. It just means that no one has offered up a decent enough visual representation of programming yet.
Another thing worth noting is that when you try to develop a high-level "wrapper" layer which rides on top of a lower-level "intermediate" layer, which in turn rides on top of a lowest-level "base" layer, that the layering prevents the top layer from being as elegant and usable as it otherwise could/should be.
Classic examples of this phenomennon:
In other words, layering forces higher layers to have to be designed to accomodate the design of the layers underneath it, which goes directly against the idea of designing the user-facing (top-most) layer for optimal usability and human understanding.
I think one of the biggest reasons visual programming has not really succeeded so far is because all the approaches to it have been attempts to "visualize" existing programming models as set forth by C/C++/Java/C#/Basic-type languages. That won't work because those programming models were never designed to be visual in the first place. This approach forces the top-most layer (the visual stuff) to be designed in a way that accomodates the intermediate layer, rather than permitting it to be designed in the most human-intuitive way.
Instead of trying to create a visual representation of those existing programming models, the right approach (whatever it is) will ultimately prove to involve an entirely new programming model constructed specifically for it, rather than reusing all the same constructs and ideas established by existing textual languages.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
While UnrealEd3 does visualize much of the content creation process, including materials/shaders, physics constraints, particle systems, AI waypoints/hints, etc. It doesn't not visualize the underlying logic. As a developing working on two Unreal projects, I'm assuming I would have heard this from Epic.
e 30.shtml
For more on UnrealEd3 (and the engine itself) look at:
http://www.unrealtechnology.com/html/technology/u
Anm