
Visual Programming Is Unbelievable (2015) - tiago_simoes
http://www.outsystems.com/blog/2015/03/visual-programming-is-unbelievable.html
======
mtanski
There is one place where visual programming is alive and well and has been for
a long time. That's programming PLC (Programmable Logic Controllers). It's
easy to forget about PLCs[1], but it's an old and large niche in large
corporations that do a lot of industrial automation like assembly lines,
(automobile) manufacturing, oil & gas...

Most PLC programming is done using Ladder Logic [2] and various visual tools
tools for creating and editing Ladder Logic. Here's a screenshot of one such
environment, RSLogix:
[https://i.ytimg.com/vi/4yEj065J1q4/maxresdefault.jpg](https://i.ytimg.com/vi/4yEj065J1q4/maxresdefault.jpg)

It's an interesting data point because A) it's a highly technical field where
accuracy (and verification) matters B) almost everybody who does PLC
programming spends all their time in a visual programming environment.

[1]
[https://en.wikipedia.org/wiki/Programmable_logic_controller](https://en.wikipedia.org/wiki/Programmable_logic_controller)

[2]
[https://en.wikipedia.org/wiki/Ladder_logic](https://en.wikipedia.org/wiki/Ladder_logic)

~~~
pmoriarty
Another place where visual programming is popular is among music producers,
with systems like Max/MSP[1] and PureData[2].

I dabbled in PureData a little, and while it seemed to be ok for simple
things, I imagine that for anything even moderately complex, it would quickly
become a nightmare.

While visual programming paradigms seem like a nice thing at first glance,
they are missing out on whole ecosystems of tools developed over many decades
for text-based programming. Things like debugging, version control, grep,
search/replace, all the features of advanced text editors like vim or emacs,
etc.

[1] -
[https://en.wikipedia.org/wiki/Max/MSP](https://en.wikipedia.org/wiki/Max/MSP)

[2] -
[https://en.wikipedia.org/wiki/Pure_Data](https://en.wikipedia.org/wiki/Pure_Data)

~~~
sebular
I don't know what your definition of a "moderately complex" program looks
like, but I have to say that from my own dabbling with PureData I really
enjoyed the way it handled the concepts of abstraction and encapsulation.

It's been long enough that I've forgotten the terminology, but I remember
thoroughly enjoying the process of first building a widget, then meticulously
arranging all of the little boxes, color-coding, and labeling various sections
until it looked visually attractive. Then when I was satisfied, I could take
that entire widget and abstract it away as a small box with only the relevant
input/output connectors.

I guess it's always just stuck out in my mind as the one time I really dug
into a visual language, and the aesthetic aspect of organizing my "code" was
very appealing. It's been a decade since I last opened any of those old
project files, but I can still picture many of the components I built with my
mind's eye. In and of itself, that's got to be worth something.

I imagine that someday we'll see the rise of a programming metaphor that works
as a hybrid of code and visual. Even though working with PureData was
inspirational, I don't see text-based languages losing relevancy any time
soon. However, I think that while text code is great for representing the flow
of logic, higher-order organizational constructs (such as class hierarchies)
might be better represented by visual relationships. If I give you a paper and
pencil and ask you to map out interconnected relationships between a bunch of
entities, you're probably going to start drawing boxes and lines-- and end up
with something that looks a lot like PureData.

Especially if you consider the potential of future iterations on today's VR/AR
concepts, I wouldn't be too surprised if programming languages eventually
looked like color-coded interconnected boxes of text code that can be
rearranged in space. It wouldn't even be that far-fetched to imagine
animations being included to enhance a programmer's ability to visualize the
flow of logic. And I don't think that such concepts should be particularly
offensive to those who consider themselves to be serious programmers.

~~~
TuringTest
_I imagine that someday we 'll see the rise of a programming metaphor that
works as a hybrid of code and visual._

You're going to enjoy the Eve language...[1][2] :-)

[1] [http://eve-lang.com/](http://eve-lang.com/)

[2] [http://incidentalcomplexity.com/](http://incidentalcomplexity.com/)

------
hacker_9
'Visual Programming' failed (and continues to fail) simply because it is a
lie; just because you surround my textual code with boxes and draw arrows
showing the 'flow of execution' does not make it visual! This core
misunderstanding is why all these 'visual' tools suck and don't help anyone do
anything practical (read: practical = complex systems).

When I write code, for example a layout algorithm for a set of gui elements, I
visually see the data in my head (the gui elements), then I run the algorithm
and see the elements 'move' into position dependent upon their
dock/anchor/margin properties (also taking into account previously docked
elements positions, parent element resize delta, etc). This is the visual I
need to see on screen! I need to see my real data being manipulated by my
algorithms and moving from A to B. I expect with this kind of animation I
could easily see when things go wrong naturally, seeing as visual processing
happens with no conscious effort.

Instead visual programming thinks I want to see the textual properties of my
objects in memory in fancy coloured boxes, which is not the case at all.

~~~
fsloth
For fairly simple configuration tasks IMO visual programming is a powerful
tool for non-programmer end users to actually create programs which are not
prone to syntax errors, misguided loop conditions or such. It also means one
does not need to learn yet another syntax. True, the application domains are
limited, but for example the common node based computational graph generation
done for example in Blender and other visual software works quite well.

It's not meant for professional programming, it's about empowering the end
user with programmable tools.

~~~
hacker_9
But at what point does simple become complex? It's all well and good saying
only use it for simple tasks, but when real life complexity comes knocking,
you end up with this sort of magic [1] that is far worse than any C++ I've
seen in the wild.

[1]
[http://scriptsofanotherdimension.tumblr.com](http://scriptsofanotherdimension.tumblr.com)

~~~
TuringTest
People interested in VP really, really should learn about DRAKON[1], the
Russian style guide for structured dataflows.

I've used it for real projects and it actually solves the spaghetti problem.
Compare this:[2] with this:[3].

[1]
[https://en.wikipedia.org/wiki/DRAKON](https://en.wikipedia.org/wiki/DRAKON)

[2]
[http://scriptsofanotherdimension.tumblr.com/image/1386972466...](http://scriptsofanotherdimension.tumblr.com/image/138697246606)

[3]
[https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cr...](https://upload.wikimedia.org/wikipedia/commons/0/0f/Dutch_cryo_Moscow.png)

~~~
fsloth
A drakon node does not seem to support multiple input values? That's why these
visual graphs get convoluted. Compute nodes deal with multiple input and
output connections.

~~~
TuringTest
Good call. Drakon is for control flow specification, not data flow
specification. However having a standard for splitting subsystems in separate
modules and laying out components using regular rules would benefit any kind
of visual graph.

------
Finnucane
"That evolution, which seems so inevitable today, brought us better graphic
cards – which lead to better games, brought us the world wide web,"

It should be remembered that in the early days of the web, some people argued
that it should remain text-only. Basically, if you couldn't read it on the
command line with Lynx, they weren't interested. Of course, the web seemed
different at 9600 baud (or even slower).

Being color-blind, I am not enthusiastic about the idea of visual programming,
just because a lot of visual tools are color-coded in ways that are hard for
me to work with, esp. if the default settings are not easily modified. Even
syntax-coloring in a text editor is a chore to deal with.

------
jerf
It is a very strange essay form to give multiple reasons why a thing has not
worked very well, then end it with the conclusion that people just
irrationally don't like it because your brain is just biased against it.

I don't believe in it in the general case simply because I've never seen a
general-purpose visual programming language work. Show me one and show me lots
of people choosing it freely and I'll believe just fine. I'm not holding my
breath, though. (There are certainly specialized ones that meet this bar.)

Most analyses of this problem fall prey to the "anything can be made to look
good if you only consider the positives of one side and the negatives of the
other" effect. Visual advocates generally make wild promises about the
positives of visual programming, which turn out to much harder to manifest
than imagine in your head, and then make silly criticisms of textual
languages, mistaking accidental issues of complexity for fundamental issues in
the language. (Visual languages, just as one example, have no special
protection against spaghetti code, any more than anything else does. Spaghetti
code is not caused by textual languages, it's caused by developers creating
spaghetti code from the spaghetti concepts in their heads.)

So not only are the analyses incomplete, examining only the positives of
visual languages and the negatives of textual languages, most of the ones I
see are even pretty terrible on those terms.

If you want do this, you need to look at both the pros and the cons of _both_
sides, fairly. And if you haven't got a solid set of positives on the textual
side and negatives on the visual side, go back and do it again.

(I'm not saying you _must_ conclude that the net benefit is to text. You may
have things that outweigh what I mentioned and your sum may come out in favor
of visual programming. I'm simply saying if you can't explain in a sensible
manner why text has been successful and why existing visual languages have
failed, you do not have an analysis. You have a wish.)

~~~
hacker_9
To add to this, I present to you screenshots of visual programming spaghetti
code in all of it's glory [1].

[1]
[http://scriptsofanotherdimension.tumblr.com](http://scriptsofanotherdimension.tumblr.com)

~~~
jimbokun
So one advantage of visual programming languages, spaghetti code literally
looks like a plate of spaghetti!

------
TuringTest
That post has no clue about the shortcomings, which were true in the past but
needn't be any longer. Programmers have been doing visual programming since
the advent of the visual debugger that shows updated values during program
execution, and they are requesting more and more of it with tools for Live
Programming like jsfiddle or LightTable (for VP in classic languages) or new
languages like Apparatus[1] or Eve[2].

We are in the middle of the Visual Programming renaissance, now that the
hurdles that limited composability of visual programs have been theoretically
solved in the last decade by Programming Languages researchers, and computers
are finally powerful enough to move visual languages without slowing to a
crawl.

Unfortunately, Visual Programming suffers the same curse as Artificial
Intelligence: for every breakthrough that produces revolutionary new tools, it
is no longer considered Visual Programming but merely "how the tools should
work".

[1] [http://aprt.us/](http://aprt.us/)

[2] [http://eve-lang.com/](http://eve-lang.com/)

------
DonHopkins
Spreadsheets are visual programming languages, and they seem pretty popular,
and have been for a while.

~~~
rbanffy
Not really. You still need to write formulas using a textual language.

~~~
DonHopkins
Or selecting formulas from menus and parameters by pointing and clicking and
dragging, directly manipulating rows, columns and cells, and addressing
parameters by relative two-dimensional offsets.

~~~
rbanffy
Selecting text from lists is not visual, neither is relative 2D offsets.

------
Danieru
At work we use a blend of C++ with Unreal Engine's visual programming language
Blueprints. I am going to be honest with you guys here: I love blueprints.

They are very limited compared, lacking even maps. When it comes to connecting
existing behavior together they are king. Consider the parts of game
development which cannot be made generic. By sticking those in Blueprints we
get nice high level code.

~~~
failrate
I was a skeptic of visual programming, but experience has taught me that
Blueprints is a good enough language for a large set of tasks.

------
rbanffy
I found it odd there is no mention to Scratch or Scheme Bricks.

[https://vimeo.com/62615513](https://vimeo.com/62615513)

~~~
fsloth
This. Scratch is the killer application of visual programming. It's
educational, yes, but it's excellent at that (from experiences from my two
kids).

------
carsongross
Visual programming does not work well mostly due to a physical problem: typing
characters into a computer is much faster and flexible at generating
imperative code than using a mouse. There are declarative domains, such as
simple UI building, where that is less true, but even then, when you kick out
to the event handler, text is much faster.

IntelliJ has done more for visual programming, by integrating visual/wizard
aspects seamlessly into a text-dominant environment, than almost all the
visual programming advocates of the last fifty years.

Visual environments do demo well, and sometimes convince businessmen that they
won't need to pay those annoying and expensive programmers so much money.
Hence its enduring appeal to the business world.

------
musesum
I think visual programming would match some problem domains very well, such as
games (Unreal Blueprints), music (Reason, Max, PD), Neural Nets (???), UI
(Quartz Composer), robotics (???), as well as the already mentioned
spreadsheets. Most of these domains focus on flow and transition of scalars.
The problem that I've had in the past with PD and MAX is in coordinating of
multiple inputs that flow into a node. Sometimes I'd have to create a special
node to properly sequence inputs. But, that is a limitation of the tool, not
the idiom.

Another problem is how to explore and manipulate a flow graph? I like the idea
of using a force directed graph. Here is one, where I mapped a visual music
synthesizer to Jeffry Heer's Prefuse toolkit:
[https://www.youtube.com/watch?v=a703TTbxghc](https://www.youtube.com/watch?v=a703TTbxghc)

Would love to explore authoring flow, using force directed graphs on an iPad
pro + pencil (and its ilk), where one could not only draw arc between nodes,
but also between convex hulls of a collection of nodes.

------
egraether
I'm currently working on a developer tool that leverages the advantages of
visualization not for writing source code, but for navigation and
understanding. Coati, a source explorer for C/C++, combines graph
visualization and source code interactively. The graph makes it easy to see
what relationships a class or a function has, while the code still provides
all the details of the implementation.

[https://www.coati.io/](https://www.coati.io/)

~~~
kelvin0
So it would be like a souped-up Visual Assist (as used in VS C++)?

------
ThomPete
Here is a comprehensive list of different visual programming languages.

[http://blog.interfacevision.com/design/design-visual-
progarm...](http://blog.interfacevision.com/design/design-visual-progarmming-
languages-snapshots/)

The issue isn't visual programming but rather that we haven't found many good
cases to use it still.

I do think visual programming is going to have a bigger and bigger impact in
things like robotics, space exploration etc where you need more tactile access
to computation power.

It's kind of like with the idea of a 3d interface. It only make sense when the
holistic whole rather than the details are important.

It makes no sense to create a 3d warehouse I can walk around when I could just
do a search and a list.

But you wouldn't necessarily want to control a robot doing repairs on your
spaceship by having to program it every time you wanted it to do something
new.

------
gk1
Similar discussion here:
[https://news.ycombinator.com/item?id=11204017](https://news.ycombinator.com/item?id=11204017)

(From my submission just 6 days ago.)

------
jbb555
The problem with visual programming is the same as those UML tools where you
designed classes with boxes then filled in the code later. First of all it's
quicker and easier to define with text than drawing. And second of all the
detail is the important bit. You can't design the high level code in isolation
and then fill in how it works. You need to build up the components from the
details and see how the abstractions emerge. And that's not very visual/.

------
pier25
Visual programming is exploding in Unreal Engine with Blueprints to define in-
game behaviours.

[https://docs.unrealengine.com/latest/INT/Engine/Blueprints/i...](https://docs.unrealengine.com/latest/INT/Engine/Blueprints/index.html)

I for myself think visual programming is not really programming, since by
following that train of thought any GUI like Photoshop Actions could be
considered programming.

------
VLM
Can't communicate visually. The translation between written and spoken words,
even made up technical words, is fast, accurate, unambiguous. Visual means
slow, inaccurate, ambiguous, which is sometimes cool for art, but not for
communication.

It would be like trying to program musically, or by touch, or by (oh no)
smell.

There is also the productivity danger of futzing, or whatever the modern term
is. In the early desktop publishing era, we were promised that instead of
taking ten minutes writing a memo, we'd type one in five minutes, but reality
was we'd spend an hour using a minimum of seven fonts and three text colors
and pictures. So much for productivity improvement! Likewise a visual
programming language would invite people with authority but no ability to
endlessly rearrange "put that box over there, looks nicer" "Make that text
red" "that needs a larger font".

~~~
yiyus
Except we can perfectly communicate visually, and we do it all the time.

It is common to draw diagrams when you are trying to understand or explain a
problem. If you want to give somebody a rough idea of how your program works,
it is infinitely more likely that you use some kind of drawing than music,
touch or smell.

I don't agree neither with visual programming inviting people to lose time in
details. The same you do not lose time thinking about how to structure a
sentence to write a program, you would not lose it changing colors and fonts
in a visual programming environment with an enforced "syntax".

I do not like visual programming (I have had very bad experiences with
LabView), but I think it may be as good (or as bad) as text if the field had
evolved differently.

~~~
wvenable
Visual communication without language is always much simpler and more abstract
than other forms of visual communication. Without invoking a language with
syntax, you simply cannot get enough information density to make it useful.

The only time we generally communicate visually is when we want to express
something with less detail (e.g. charts, diagrams, graphs, emoji, etc).

------
staticelf
The title sounds like it comes from BuzzFeed.

------
127001brewer
_...otherwise you might just end up in the wrong side of history._

And I don't believe it worked within the US Army [0][1][2] - unless I'm not
correctly remembering the history of Outsystem's Visual Programming there...

[0] [https://www.outsystems.com/company/news/2012/outsystems-
us-a...](https://www.outsystems.com/company/news/2012/outsystems-us-army/) [1]
[http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_f...](http://www.army.mil/article/96352/SEC_s_Cloud_Mil_solution_for_DoD/)
[2] [http://www.afcea.org/content/?q=us-army-innovates-cloud-
comp...](http://www.afcea.org/content/?q=us-army-innovates-cloud-computing-
front)

------
rajatrocks
I interned at VPL Research[1] in 1992 and they had a Mac-based VPL for
controlling objects in VR called Body Electric[2] that was really fun to use -
especially since I'd never seen anything like it. I implemented gravity for
objects and a virtual arm using it. If I remember correctly, debugging could
be a challenge. It was later interfaced with Macromedia Director[3] to control
desktop apps.

[1]
[https://en.wikipedia.org/wiki/VPL_Research](https://en.wikipedia.org/wiki/VPL_Research)

[2] [http://www.jaronlanier.com/vpl.html](http://www.jaronlanier.com/vpl.html)

[3]
[http://www.art.net/~hopkins/Don/lang/bounce/bounce.html](http://www.art.net/~hopkins/Don/lang/bounce/bounce.html)

------
aniijbod
Software developed using visual programming languages often has the
potential/necessity to include content which constitutes a 'visual/non-visual
hybrid' as the application becomes more complex: the boxes to which arrows are
connected usually contain things which are lines of text/symbols/formulae,
i.e. are not 'diagrammatic'. Visual programming languages tend to use diagrams
for structure and 'notationally rich text' for content and are therefore
addressing requirements for simplifying the representation of and increasing
the intelligibility of the structure of application development as their
highest priority. The reason why this rationale can seem to be problematic is
because justifying/achieving the job of meaningfully 'separating structure
from content' in software brings it's own highly contingent/subjective
challenges (as any detractor of object-oriented design will be aware). For
instance, how far could/should you go in trying to 'diagrammatise' the
notational content of boxes in a boxes and arrows language. Is the fact that
you are diagrammatising the app at all enough of a benefit in terms of
reducing the learning curve/programming aptitude requirement, such that
'further/total diagrammatisation' is nothing more than a 'diminishing returns'
consideration? What criteria do you use to decide the 'diagramtic benefit
limit'? The biggest growing business in software development today is 'triple
A games development' and visual programming languages are used as a way of
giving designers the means to create content and gameplay without requiring
the designer to have programming skill levels that match those of developers
(developers can then optimise the designer's work by converting it into C++ to
get the frame rate up and integrating it with the rest of their native
codebase). Here's an example of an impressive case in point done in UE4
Blueprints without a single line of C++:
[https://www.youtube.com/watch?v=EjCandEgtHo](https://www.youtube.com/watch?v=EjCandEgtHo)

------
bantunes
I don't get it - isn't the Outsystems Platform (following the link from the
blog) a visual programming environment? This article seems very odd coming
from Outsystems itself. What am I missing here?

~~~
zapov
They are probably dissatisfied with developer stance toward their RAD
framework.

I'm sure various business apps can be built successfully on top of their
Visual programming IDE, but even Microsoft has mostly abandoned that route.

But I dislike that even they propagate the lie that systems are slow when
built on top of "High level language". That is mostly an optimization problem
and you can often optimize well beyond what people would be willing to do in
lower level language.

------
tluyben2
I worked quite a bit with Outsystems and like with all the tools that use
boxes(/balls) with lines between them as 'visual programming', it depends
largely on how you organise things if / when it becomes a big mess. After a
while of working with it we usually just wrote what we needed in C# and when
we had very abstract things hooked them up. It looks/works well but needs a
lot of discipline (and thus training) and it's crazy expensive (for what it
does) imho.

------
vmorgulis
No mention of the Deutsch limit:

[https://en.wikipedia.org/wiki/Deutsch_limit](https://en.wikipedia.org/wiki/Deutsch_limit)

------
anthk
Smalltalk is pretty close. I use the GNU one (yeah, I know about Pharo) and is
awesome you can switch between a Smalltalk scripting and the VisualGST
browser.

------
blt
Is there any visual programming language well-suited to implementing complex
data structures like red-black trees? What about a recursive descent parser?
File system?

I have not used visual languages extensively, but it seems like they are
better suited to simple control flows with flat data structures and limited
state mutation. This would explain their success for graphics shaders, audio,
industrial control, etc.

------
im_down_w_otp
Quartz Composer is a pretty effective visual programming environment. At least
as far as a particular problem domain is concerned.

~~~
felixbraun
To illustrate of what is possible with Quartz Composer:
[https://youtu.be/eUEr4P_RWDA](https://youtu.be/eUEr4P_RWDA)

------
AshleysBrain
We use a visual programming system in our startup's game development tool
Construct 2 [1].

We may not be Visual Basic big (yet!) but we're running a successful business
on a visual programming IDE with lots of users who love it!

[1] [https://www.scirra.com](https://www.scirra.com)

------
kelvin0
I have many time mused at having visual elements integrated into your code, to
better explain or schematize some concepts (which many times cannot be easily
explained by mere comments). The future is not visual programming, it's
augmented textual programming (ATP). You heard it here first folks.

------
n2dasun
I used RAPTOR in a generic programming class at community college when trying
to get into grad school 3.5 years ago. I was somewhat impressed with it,
despite the bugs.

[http://raptor.martincarlisle.com/](http://raptor.martincarlisle.com/)

------
fsloth
Visual programming is doing quite well in editing computational graphs in
software such as Maya or Blender.

------
murukesh_s
IMO, Visual programming does not have a proper definition yet. Coding frontend
and coding backend are altogether two different things and sometimes users
confuse the application of visual authoring (programming) in one area with the
other.

But I believe it is the future. I bet you won't be carrying your laptop,
enslaved by the physical keyboard, which is necessary for traditional 'coding'
with you in 2030. You would be dragging and dropping stuff, perhaps in Virtual
reality headset or through voice or gesture to build what you want, just like
you would author in a visual platform like Adobe illustrator or in a 3d
authoring tool.

Visual programming have it's own strength and weaknesses. For e.g. Creating
algorithms from scratch in a Visual programming is not very productive (yet),
but authoring business logic is highly effective in Visual programming. How
many times, as a regular programmer you have had to write an algorithm? Most
often it's just business logic that we tag under the category of an algorithm,
which is not right. Algorithms are very generic piece of logic and business
logic applies to your own problem/data specifically. If you have a closer look
you realize that we are simply reusing algorithms or modules (created by a
smaller group of people comparatively) to build the rules/business logic. What
we do is mostly write glue code. we don't really need to code for that.

There are tons of examples for highly successful application of visual
programming. But as an average web developer you never get to see that. Reason
- Visual authoring tools are highly expensive and hence are confined to
fortune 500 companies. That along with lack of quality open source
implementations are the reason for visual programming to never take off among
general web programming community. Even the newer generation ones like
Treeline (for backend) and Bubble.is (frontend) are also closed source. NoFlo
is open source and it almost started to create some buzz, but the team got
sidetracked apparently, and they are using dataflow method for authoring
frontend which is a highly inefficient.

You want to see successful application of Visual programming in real life?
Ever heard of Enterprise Application Integration (EAI) ? Business Process
Automation (BPMN/BPEL) ? Extract Transform and Load (ETL)? They all employ
Visual programming to a great extend and are multi-billion dollar businesses.
Do a google image search of following, in no particular order.

Dell bhoomi (EAI)

Tibco Business Works (EAI)

Snaplogic (Founded by Informatica ex. CEO) (EAI)

MuleESB/Anypoint studio (EAI)

Oracle BPEL (Business process automation)

Tibco iProcess (Business process automation)

Mendix (Web app development)

Webratio (Web app development)

(+lots of others if you dig out)

~~~
wvenable
> I bet you won't be carrying your laptop, enslaved by the physical keyboard,
> which is necessary for traditional 'coding' with you in 2030.

I disagree. I wouldn't have thought that Microsoft, author of Visual Basic,
would be basically forced in 2015 to add improvements to their console system
-- but here we are. If anything text-based programming is more prominent now
than in the last 10 years.

> You would be dragging and dropping stuff, perhaps in Virtual reality headset
> or through voice or gesture to build what you want, just like you would
> author in a visual platform like Adobe illustrator or in a 3d authoring
> tool.

Your arms will get very tired.

> but authoring business logic is highly effective in Visual programming.

I disagree. We have one giant visual-programmed workflow solution and it's a
very modern and powerful system but it's also insane to work with. You can
describe the problem in text with much clearer than trying to follow a diagram
that won't fit on a dozen screens in either direction.

> Reason - Visual authoring tools are highly expensive and hence are confined
> to fortune 500 companies.

They are snake-oil; nearly something you can only sell for millions of dollars
to people who make billions of dollars. You need a team of highly paid expert
consultants to make changes because nobody else knows these systems or wants
to know them. It's like going back 30 years in terms of expressive power.

~~~
murukesh_s
>Your arms will get very tired. Ha ha, What about voice? Even without fancy
stuff like gesture or voice, actually it wont be tiring. In fact if you prefer
to use keyboard, you can solely work using pure keyboard to perform all of the
visual wiring using configured shortcuts. It would be then much less effort
(in terms of typing) that in traditional coding, as you don't need to do any
boilerplate coding.

> I disagree. We have one giant visual-programmed workflow solution.

Why couldn't you break it up into multiple sub-workflows?

> They are snake-oil

Agreed. we need great open source solutions to move the needle from where it's
been stuck for over several decades.

~~~
wvenable
> Why couldn't you break it up into multiple sub-workflows?

Oh it _is_ broken up into multiple sub-workflows. There is even a way to call
workflows like functions and there is a workflow that decodes XML.

------
gat-bitty
I loved using labview when I was in test automation

------
GFK_of_xmaspast
Gnu Radio Control is a perfectly fine visual language for its problem domain:
[http://www.joshknows.com/grc](http://www.joshknows.com/grc)

