The last (natively compiled) program I wrote to run on the Windows OS was done using an almost completely visual programming tool called ProGraph [1]. It worked well, and the small cards containing the code made sure you didn't put too much logic in one picture (much like the character limit Forth imposes on its page size). The system lives on as Marten [2], but only supports Mac OSX now.
While there are some things I like about visual programming, there are also many issues - perhaps the biggest is that it lulls the developer into believing they don't need to understand the underlying computer. I think a similar analogy is how a newbie RoR developer can create a CRUD application without ever looking at or understanding the scaffold-generated code.
I've thought about this a lot (in fact, years before I found ProGraph I tried to develop a system I called FloPro which was standard Fortran flow-charts on the front end and generated C (to compile on your local platform) on the backend), but I haven't seen a solution to these problems in any visual programming system.
At the risk of some criticism, I would like to make some visual language comments. I am the author of a visual language programming environment called Marten which supports the Prograph visual language. I use this IDE everyday to write commercial-grade software for clients. Marten is in fact written in Prograph using Marten. I have created software in many other languages such as FORTRAN, RATFOR, C, C++, C#, Objective-C, Java, Perl, Python, along with i386 and PPC assembly, so I am very familiar with the difference between programming in a text-based language and visual programming. I found that visual programming is so superior to using text-based languages that I wrote my own IDE to ensure that I could continue to do so. Consequently, Marten stands as an example that not only is visual-programming not "vaporware", it can be an valuable and powerful addition to a developer's toolkit.
While there are some things I like about visual programming, there are also many issues - perhaps the biggest is that it lulls the developer into believing they don't need to understand the underlying computer. I think a similar analogy is how a newbie RoR developer can create a CRUD application without ever looking at or understanding the scaffold-generated code.
I've thought about this a lot (in fact, years before I found ProGraph I tried to develop a system I called FloPro which was standard Fortran flow-charts on the front end and generated C (to compile on your local platform) on the backend), but I haven't seen a solution to these problems in any visual programming system.
[1] http://en.wikipedia.org/wiki/Prograph [2] http://www.andescotia.com/products/marten/