Visual Programming Is The Future Of Computing

Not the future of computing... the future of small LOB apps written by fred in sales to keep track of things the CRM software doesn't, or tony in logistics to keep track of stuff that isn't covered by the warehouse management system.<p>Like VB (pre .net) &#38; Access this will allow the average business user to suddenly create computer software suited to their individual task... and become the bane of IT once it becomes "mission critical" (in the sense that the business looses serious productivity without it) as it will be developed in such a way that "works" but is terribly inefficient. This is not always a bad thing, there can be considerable wisdom in letting these tools develop and not spending real development resources on them until they have proved their worth.<p>I believe visual programming will become a tool for the serious programmer the day you can reliably visualize a code base like postgreSQL, firefox or Open Office, patch a bug, submit a couple of line diff and have the other contributors none the wiser. Until that point in time I feel it will be nothing but Hypercard with a new coat of pain.<p>That being said I could see visual programing interface as an improvement on the GUI builder type tools (.Net, Delphi, XCode) where you not only design the static layout, but are able to design animations and transitions visually.

Of course it's the future; it's also the past and present. Programming is deeply visual. Any doubt about that, just listen to ruby guys (and gals) praise its gorgeously delimited blocks. Or why do python coders love list comprehensions so much; and javascript folks the ternary operator? Much of the appeal of those agglomerations of symbols is absolutely visual.<p>If V/P can encode more information on my 40 x 85 editor window, using some other paradigm than what's possible using words plus $@?{(&#62;=+/ then i'll gladly switch. At the moment though, good programmers can easily outrun the state-of-the-art V/P exemplars; my criticism of diagram-to-code tools like Altova UModel (UML-to-Java) or MicroOLAP's Database Designer (UML-to-SQL) is just that i can code more quickly than i can drag boxes and arrows around. i just don't see the coal-powered engine out-running the horse anytime soon.

Visual programming may be the future of learning how to build applications, but it's not "the future of computing."<p>The pattern of visual introduction followed by symbolic mastery occurs again and again:<p><pre><code> 1. Learning to count using physical objects 2. Learning arithmetic using number lines 3. Learning trigonometry using triangles 4. Learning geometry with compasses and straight edges 5. Learning to speak before learning to write 6. Learning macroeconomics via guns &#38; butter </code></pre> and on and on...<p>Visual programming is a great tool, and if we can somehow capture the non-programmer's imagination and guide them to an understanding of controlled flow, subroutines, event handling, multiple threads of execution, etc., then we may get them to the point of converting those notions into written code (the symbolic form of the above). This would be a giant leap forward for empowering users over their individual computing environments.<p>But let's not fool ourselves and pretend that this is the future of programming for either novices, amateurs, or professionals.

I think a visual/natural language command line could be the future of UIs. To get people to use basic visual programming tools instead of relying on trivial apps made by others, you need to force them into it, like BASIC did on old computers. If the divide between programming and general UIs for everyday tasks was reduced, people would be much more receptive of programming. It would involve the same type of thinking they'd practice daily.<p>OSX Automator makes a whole class of quickie apps redundant. Batch renamers, resizers, converters are a few autocompletes and drag and drops away. Mathematica and Wolfram Alpha let you do annoying little programming tasks with a large library of curated functions accessed with autocomplete/natural language - <a href="http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/" rel="nofollow">http://blog.wolfram.com/2010/11/16/programming-with-natural-...</a><p>A visual/natural language command line could do the same for general computer use. Instead of finding some tiny poorly designed buttons in a giant app, you'd type in what you want and find it faster, foregoing the usual step of the application's help. A simple example would be removing red eye in photoshop. Finding that tool for novices is the full app is impractical. So they're forced to get dumbed down photoshop where the tool's placement is more obvious. Instead they could have typed red eye, scary eye, fix eyes, into the full app.<p>Also the placement of red-eye remover is so obvious in basic photo editors that they leave little room in the UI for other common tasks. What about make skinny? Remove wrinkle/pimple? Those become far harder to present with the GUI paradigm. Heal brush and liquify are not helpful names for novices.<p>The modern GUI strayed too far from the command line in order to remove modes and make computers novice friendly. Other directions weren't thoroughly explored.

Ugh. No. I've recently had the bad luck to debug a program in National Instruments' LabView. I felt like screaming and tearing down walls. On the other hand, the best visual programming experience I had was Pentaho's Kettle ETL tool, and even that I still prefer to write code.<p>EDIT: Ah, I noticed the author mentioned LabView, and I very much agree with this statement:<p>&#62; But the average user doesn’t need that!<p>&#62;But those tools give people power. They enrich lives. They save time. They make previously impossible (or close to impossible) tasks… possible.<p>I disagree with this:<p>&#62; And that is what Visual Software Creation is all about.<p>Please, by all means teach people programming and basic algorithm. Visual programming is still a terrible shortcut.

General-purpose visual programming will only succeed for pure functional programming languages, and even then, it will only succeed when people realize that programs are graphs, not lists or trees. He says.

I think Visual Programming is best with the User Interface creation mechanisms, but aside from that, it is much, much harder to handle projects of any side using only the Visual Programming paradigm.

Most applications need to CRUD. They need drop downs and tabs. That's why we have visual designers for forms. That's why we have Content Types for CMS. So there are definitely patterns that we are extracting out into user-configurable interfaces that don't require coding.<p>That true for most things. Computer games need editors for game designers to manipulate the environment. Spreadsheets allow for any type of equation to be entered etc.<p>With 'workflow' editors you can even get into a lot of logic configuration in a practical way.<p>Its not practical to try to encode everything that way, but quite a bit of the stuff that is being sort of repeatedly coded in different ways is the type of thing that we really could just have widgets or configuration screens for if we were reusing code properly. <a href="http://en.wikipedia.org/wiki/Intentional_programming" rel="nofollow">http://en.wikipedia.org/wiki/Intentional_programming</a>