I have a strong interest in visual programming. Many programmers say it is not practical but they are ignoring its big success in CG. Most highend CG softwares have a node tree/graph and it is a visual programming environment in a sense.
Currently people are still making small ad-hock scripts for daily works if there's no appropriate tool exists, renaming files, file type conversion, registering something to another, opening a file, add some comment on it, save it and close it, find something in a file, replacing it, brabrabra... and the repeated execution of mixture of them. In big productions lots of works are automated but still they are doing a lot like this for non-procedual works daily.
In my opinion it's absolutely ridiculous to make scripts for them. Why do we have to make scripts for such small things? But currently there's no easier way.
There are several reasons why Python itself is not perfect for this reason.
- A module is too big to back-up dozens of smallest code snippets for later use.
- If a module has been changed, it'll be affected by all the scripts that uses it.
- Scripting is not intuitive.
- Python itself is not a tool to find a code snippet quickly.
- Try and error is not easy. Often you need to re-run a script.
(You may think "No, it's not. Everything listed here is so easy in Python", but I'm thinking of them from a point of view of non-technical people)
Several years ago I made a prototype of a Python based visual programming framework. It's target is artists who are not so much familiar with scripting. You can change the node network dynamically and see the result immediately, registering the node for later use, and reusing it by cloning. A node itself is a code snippet as well as a GUI representation tool so the user can relatively easily find where to look at when he is modifying the network .
You can find more information, and several capture movies here.
I'm making it with a German guy. Currently the project is almost frozen but I'm still hoping to release ver.1
I cannot say a lot cause we may release it commercially but he is looking at the tool from a different aspect, i.e. for professional programmers so it'll be a much larger system than what you would imagine after reading this post.
Wednesday, September 3, 2008
Visual programming
Subscribe to:
Post Comments (Atom)
4 comments:
I think the only real problem with visual programming is that its advantages must be applied from a foundational level for the language to succeed; if the underlying concepts are a reapplication of typical imperative style, then only the downsides become visible.
Audio programming has several examples of visual interfaces. See Pure Data and MAX/MSP. Subtext (subtextual.org) is an example of a more general-purpose language.
There is also Envox studio that is used for visual programming of applications in computer telephony. See http://www.envox.com/software/envox-7-studio.asp. It is quite good for the job and the programing with it is very easy.
I prefer to call it graphical programming as the operations, etc, are represented by graphics.
In the past I have successfully used Prograph for several types of applications: a highly interactive graphical editor for designing weaving patterns, a server side scripting platform (comparable to asp, jsp, php) and several client-server database appications.
With Prograph I had the best programming experience ever. It is not a scripting language. You make real binary applications. Have a look at www.andescotia.com for the currently only Prograph IDE, called Marten.
Hi,
Thanks for the list of applications. We can add LabVIEW as another successful application.
> I think the only real problem with visual programming is that its advantages must be applied from a foundational level for the language to succeed; if the underlying concepts are a reapplication of typical imperative style, then only the downsides become visible.
Good point. if it's a wrapper of a scripting lanuage, it does limit the strength of the language, for example, I don't know how to make a thread programing with my implementation, and because my one itself is a framework it's not easy to use another framework, twisted for instance. There will be a lot other.
Still I think visualizing itself is a big advantage for many people. I work with artists and many of them don't have a sense of scripting. They don't know exactly which nodes are evaluated on what timing and what data type is passed between nodes, but they still can make a script and do whatever they want with it.
Another benefit is that depending on its implementation, when you change the state of a network of nodes, it can be reflected to the execution state immediately. For example, when you have some trouble making something on my prototype, you can save it, give it to your friend, your friend opens it, add some diagonostic nodes to the network and detect what's making wrong. I know it is not intrinsic but I find no practical way to do it without visual environment.
olmeca,
Yeah I've heard the name Prograph as a successful software in this field. Unfortunately what I think most important for my usage is runtime modification of the program and immediate reflection to the execution state which I mentioned above. Prograph is something for professional programmers imo.
Post a Comment