
Visual Programming Is The Future Of Computing - nuromancer
http://lunduke.com/?p=1500
======
jlawer
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.

Like VB (pre .net) & 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.

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.

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.

------
doug1001
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.

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 $@?{(>=+/ 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.

------
fabricode
Visual programming may be the future of learning how to build applications,
but it's not "the future of computing."

The pattern of visual introduction followed by symbolic mastery occurs again
and again:

    
    
      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 & butter
    

and on and on...

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.

But let's not fool ourselves and pretend that this is the future of
programming for either novices, amateurs, or professionals.

------
Detrus
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.

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 - [http://blog.wolfram.com/2010/11/16/programming-with-
natural-...](http://blog.wolfram.com/2010/11/16/programming-with-natural-
language-is-actually-going-to-work/)

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.

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.

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.

------
chewxy
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.

EDIT: Ah, I noticed the author mentioned LabView, and I very much agree with
this statement:

> But the average user doesn’t need that!

>But those tools give people power. They enrich lives. They save time. They
make previously impossible (or close to impossible) tasks… possible.

I disagree with this:

> And that is what Visual Software Creation is all about.

Please, by all means teach people programming and basic algorithm. Visual
programming is still a terrible shortcut.

~~~
__float
LabVIEW! I, too, recall my mixed feelings when I started with it. It's much
easier for people who have never programmed before--there's no weird syntax to
learn (why can't I use = to compare?)--but I've found resistance in said users
not wanting to move on to a language with widespread, real world use (like
C++).

Is it worth starting with it? I'm not entirely sure. I'm under the belief that
such "difficult" hurdles from which a visual programming language protects one
are best learned while still learning the simplest concepts.

------
taliesinb
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.

------
smashing
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.

------
ilaksh
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.

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.

With 'workflow' editors you can even get into a lot of logic configuration in
a practical way.

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.
<http://en.wikipedia.org/wiki/Intentional_programming>

