
Ask HN: Why does visual programming suck? - dvdhsu
Almost every visual programming tool I&#x27;ve seen on HN looks so cool when I see the gif, but when I start using it, it&#x27;s invariably a frustrating experience. I think it might be because customizing the last 20% is difficult visually, and you so you have to drop down to code. But once you&#x27;re in visual programming land, changing abstraction layers is difficult.<p>When I asked Alan Kay this question, his first response was &quot;well there are various types of visual programming, some of them have taken off&quot;. The type of visual programming I&#x27;m thinking about here is a WYSIWYG drag and drop interface for building UIs. Imagine having prebuilt views (tables, buttons, dropdowns, etc.) and being able to drag them and lay them out how you want. Then you interact with their API: this table pulls in data from this SQL statement; this button executes this HTTP query; this dropdown publishes this value, which this SQL statement uses via string interpolation. These &quot;widgets&quot; publish their data, which can be used by other widgets (w1.value), and inside SQL queries. The tables can pull in data from SQL queries. You can use string interpolation inside SQL queries, so dropdowns can influence the query being run. So selecting a drop down value would cause the query to change, which would automatically propagate changes to the table.
======
devcriollo
"Text is the most socially useful communication technology. It works well in
1:1, 1:N, and M:N modes. It can be indexed and searched efficiently, even by
hand. It can be translated. It can be produced and consumed at variable
speeds. It is asynchronous. It can be compared, diffed, clustered, corrected,
summarized and filtered algorithmically. It permits multiparty editing. It
permits branching conversations, lurking, annotation, quoting, reviewing,
summarizing, structured responses, exegesis, even fan fic. The breadth, scale
and depth of ways people use text is unmatched by anything. There is no
equivalent in any other communication technology for the social,
communicative, cognitive and reflective complexity of a library full of books
or an internet full of postings. Nothing else comes close."
[http://graydon2.dreamwidth.org/193447.html](http://graydon2.dreamwidth.org/193447.html)

~~~
kbuchanan
I agree with this statement, wholeheartedly.

I do, however, think programming languages could benefit from more visual
_augmentation_. A program, over time, takes on more complexity than a
programmer can hold in his mind, and eventually, the program's design will
elude him. A disconnect appears between the text he types _in the moment_ and
the original _design_ of the program. The sum total of the program's code no
longer resembles the problems at hand.

Here, I think, visual tools are underutilized. Not as code crafting tools, but
as tools for reflection. Reflection on dependency trees, deviation in style,
orphaned code, the ability to visualize how and where data might flow in
unexpected ways, etc. Webpack's stats.json comes to mind for dependency
tracing. Statically typed languages obviously have a leg up here.

~~~
vosper
I have a dream that one day we'll collectively realize that "buying
programmers the best tools" means the most powerful, and not the shiniest.
Then we'll all be running ultra-wide monitors with room for many different
visual aides on the one screen, backed by the CPU horsepower (overclocked and
liquid cooled, if necessary) to make it all fast. And, hopefully, we'll see
what an IDE can really be.

~~~
aargh_aargh
My dream is the opposite. Constrain programmers to hardware that's 2
generations old. That will force us to make our programs run fast in this
environment which is much closer to what actual users will use to running it.

I do understand the implication that lowering the need for always faster
hardware for end users will slow down the pace of development of new hardware.
But with the end of Moore's law upon us, that's inevitable anyway.

Our computers are plenty fast today, beyond what we could imagine when each of
us started programming. Let's cut down on abstractions. Let's profile,
optimize.

~~~
IceDane
After being stuck with a really, really bad laptop for the past 4 years, I
can't disagree more whole-heartedly. I wouldn't wish that experience on my
worst enemy, heh.

Though I wish more time was spent on some tools to make them more memory
efficient(I'm looking at you, scala and friends), that's just not how it is
today. I just bought a new laptop with 32 gigs of ram, and hopefully that is
future-proof for the next few years.

~~~
DanBC
What was the laptop? And what were the 3 things that you found most annoying?

~~~
IceDane
A bit late reply.. but the laptop was just the cheapest laptop I could buy
before starting Uni, roughly 4 years ago. I just got my new laptop a couple of
days ago, and the difference is incredible.

The other guy that replied to your comment is basically right. My old laptop
had a measly 4GB of RAM, and opening multiple tabs in Chrome for
documentation, running an editor, some development tools like REPLs etc, and
I'd basically be out of RAM. I would literally listen to music on my phone
because spotify consumed too much of my precious RAM, and I had to kill off
tabs that I hadn't used for a while like it was Survivor, in order to keep my
laptop from start swapping(which means everything grinds to a halt).

I even run a very minimalistic window manager and don't use IDEs like IntelliJ
or anything.

------
mvindahl
I think visual programming is one of those ideas that intuitively seems like a
good idea but never is. Thus, it never really dies, it just gets picked up as
a kind of rite-of-passage by new generations of developers. Managers also tend
to like the concept as it would allow them to bypass the pesky code monkeys
and just feed their drawings to the computer.

For my master's thesis, some 15 years ago, I programmed a system for visually
composing and executing Java programs. The UI looked a bit like UML, and it
worked nicely for anything resembling "Hello world" complexity (anything more
complex literally became hairy to look at). Since then I've twice found myself
on projects where we had to work with visual programming tools (caused by
skilled salesmen and inept managers). In both cases the only sensible action
was to pound the "eject" button until we were catapulted away from the
monster. All in all I consider myself vaccinated at this point.

As for my reply to the question of the OP, I'm not sure that it differs much
from everyone else. The main reason that it will never catch on, IMHO, is that
the text editor is far better for managing complexity. It's easy to search for
stuff, and it's easy to move or copy it. Also, every serious text based
programming languages offers plenty of ways to hide complexity away, allowing
you to focus your thinking at the desired level of abstraction. Visual
programming tools -- or at least those that I have met -- instead force you to
deal with stuff that doesn't matter (such as aligning boxes and arrows), and
views very quickly become cluttered when you start connecting things.

That being said, I think visual tools can be a good fit for tasks whose output
is UI. There are applications and frameworks that allow you to drag'n'drop to
compose the UI, but the code is still written in a text editor. This can work
reasonably well.

~~~
revelation
Except there is a successful visual programming tool and it probably runs a
large chunk of software in your car. It's called Matlab Simulink:

[https://mathworks.com/help/simulink/examples/anti-windup-
con...](https://mathworks.com/help/simulink/examples/anti-windup-control-
using-a-pid-controller.html?prodcode=SL)

Obvious lectures from this:

1) Don't be silly and copy a text based language into visual blocks. Nobody
wants to drag&drop the components of a while loop or click a box to enter a
variable name. If you have variable names, you probably failed this one
already.

2) It's about the data, stupid. There is very very little explicit control
flow in Simulink diagrams. Instead it's all about the flow of data.

3) Seriously, nobody wants to click together while loops. Simulink works
because it has a very large and very powerful library of blocks that you need
just a few of at a time to build very complex functionality.

~~~
mvindahl
That's actually very interesting. Never heard of that before.

A few remarks off the the top off my head:

1) Visually, it reminds me of electrical diagrams, perhaps taking it one or
two steps up the ladder of abstraction. I can see how it might be an appealing
notation for someone trained in electrical engineering, which may explain its
usage in cars. It's really interesting how different "cultures" find different
solutions to similar problems.

2) Still, and this may be unfair since I only glanced over it for a few
minutes, it strikes me as more of a niche thing than as something that I'd
describe as a general purpose language. It seems fixed at a certain level of
abstraction. Probably just the right level of abstraction for configuring your
car firmware, but impractical for authoring a complex piece of desktop
software.

Maybe the future will prove me wrong :)

~~~
bzalasky
Perhaps creating niche visual DSLs is a more viable approach to developing
visual programming environments than to focus on creating a general purpose
programming environment.

It'd be interesting to see if there are any existing solutions in other
domains.

------
Changu
I think the reason is that text is already a highly optimized visual way to
represent information. It started with cave paintings and evolved to what it
is now.

"Please go to the supermarket and get two bottles of beer. If you see Joe,
tell him we are having a party in my house at 6 tomorrow."

It took me a few seconds to write that. Imagine I had to paint it.

~~~
nikofeyn
then why does everyone sketch a picture when trying to convey an idea? text is
obviously useful but so is visual information. the complete dismissal of
visual programming by text-based programmers is often infuriating. visual
programming can provide an immediate indication of structure and dataflow,
something that text-based languages struggle with.

in my mind, the best case scenario is some sort of hybrid, where visual and
text representations take over on what they're best at, yielding to the other
when it makes sense. the way people work on mathematics is a great example of
this. drawings, diagrams, graphs, shapes, etc. are used to convey structural
information where text and symbols are used to convey more detailed,
descriptive information.

~~~
baddox
> then why does everyone sketch a picture when trying to convey an idea?

Does everyone do that? I think I very rarely do. When I need to convey an idea
on a whiteboard, it's still almost completely text, with a few extra symbols
like directional arrows that I think are still effectively just symbolic
written language.

Literally the only time I can remember sketching a picture to convey an idea
is while playing Pictionary. The entire premise of that game is that it is
much more difficult to get someone to say a specific word by drawing a picture
than by simply writing down the word.

~~~
analog31
Sometimes they do. In my view the most prominent example is documentation for
installing computer hardware and software on Windows computers. The
instructions will be a series of pictures, with circles and arrows, and a
paragraph on the back of each one (sic). This goes on for page after page. And
when the OS is updated and the dialogs all change a bit, the documentation
becomes confusing or even obsolete.

In contrast, the instructions for the Linux version of the same thing will be
something like:

    
    
        sudo apt-get install this
        sudo bing bam boom
        ...

~~~
PhasmaFelis
I also hate that, but I always felt it was more a failure of the documentation
writer than the GUI. "Click File -> Settings -> Whatever, open the Something
tab, and click the "Do It" button under the Stuff subheading" can easily
replace half a dozen unnecessary images.

~~~
Too
GUI is documentation. If you have to document how to use your GUI you are
doing it wrong.

~~~
PhasmaFelis
It's not practical in a modern operating system to put every possible function
at your fingertips and intuitively discoverable. There are better and worse
ways to organize things, but there's just too much stuff to put all off it
front and center.

GUIs are still _much_ better than a command line in this respect, since with a
GUI it's actually _possible_ to find what you're looking for by randomly
exploring, even if it's not always quick or practical.

~~~
analog31
One issue with GUI's is that you're sometimes stuck telling someone how to use
a GUI that you didn't develop, for instance having a user manipulate settings
in the device manager, which was created by Microsoft.

One thing that's rapidly improving on the command line side is Search. On my
modern Windows computers (8 and 10), I don't search for things by hand in the
dialogs any more. I press the Start button and start typing text.

For instance, Start plus "device manager" brings up the device manager,
whereas I have no idea how to find it in the menus.

------
threefour
Imagine a world where people only bought bespoke suits. You go to a tailor and
are measured and pick out your fabric and wait a few weeks. Then you pick up
your suit. It's perfect. You pay $5000 and take it home.

Most of us don't do that. Most of us make due with off the rack suits with
some tailoring for 1/10th the price.

With programming we have an expectation of bespoke design, so anything less,
even if it's much easier, seems lame.

A potentially useful reframing of the question is, "What are all the common
use cases that could be solved sufficiently with significantly less effort
using visual programming?"

~~~
dsjoerg
you win the prize for asking the right question. the answers are like with AI,
where once it's done in a certain domain, then that's not AI anymore. that is,
with visual programming, once it's done in a particular domain, people don't
think it's programming anymore.

the big examples i have in mind are: * spreadsheets -- very visual,
everything's in a grid. the relationships are spatial. * electronic music --
people lay out their various effects in a flowchart format and chain them from
one to another * video games -- consider a game like RimWorld. you're clicking
on all kinds of things and specifying what you want done with them. the
behavior of the actors in the environment are modified by your specifications.

So, it's all in various optimized subdomains. As it should be!

~~~
majewsky
Sooo... Minecraft is a visual programming tool, then?

~~~
jimsmart
Well, in light of the fact that someone built an emulator of the 6502
processor in Minecraft [0], it would be difficult to argue that it's a not
visual programming tool! (of some kind at least ;)

[0] [https://www.theverge.com/2012/5/21/3032765/minecraft-
emulate...](https://www.theverge.com/2012/5/21/3032765/minecraft-
emulated-6502-cpu-redpower-2)

------
skadamat
The way people have implemented visual programming has turned out to be a bit
of an oxymoron. Visual and symbolic are entirely different channels of
representation & understanding (for the most part). Representing a program
using lines of code and throwing some "visual magic" to spread out lines of
code across a screen doesn't take advantage of what EITHER visual or symbolic
manipulation has to offer.

Visual programming efforts have tried to visualize code and operate at the
wrong abstraction. Programming is just the act of creating programs. In a
visual programming environment, the author / programmer should use visual
interactions to "write the program". This means a few things needs to be
considered:

\- the representation - how is a computer program represented? how is state
represented? \- direct manipulation - imagine using a tool like Photoshop
having to compile / build to see your changes between every edit. \- input
devices - mouse / keyboard works for writing lines of code. Touchscreen is a
better input device / interface for visual programming but still lacking (no
tactile response).

In my opinion, not enough is reinvented when visual programming efforts are
tried. I think the entire stack (human input --> program state) needs to be
reinvented and reconsidered. Bret Victor has a great section on visual program
in his FAQ for one of his talks -
[http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...](http://worrydream.com/DrawingDynamicVisualizationsTalkAddendum/)

~~~
nzonbi
I have been working on xol, a graphic based programming language.

xoL is a graphic based programming language. It represents programming
concepts with graphics instead of text. It is product of a long, painstaking
design effort, to get an optimal graphical presentation of programs. A good
description of it is available in this blog post:
[http://lignixz.github.io/blog/posts/17/xoL_graphics_based_pr...](http://lignixz.github.io/blog/posts/17/xoL_graphics_based_programming.html)

A partially working prototype from a previous version is available online. The
newer current design has fundamental improvements over that previous
prototype. The way some program elements work was redesigned. The control
method was also redesigned. It is now aimed primarily at touch based controls.
Here is the prototype for the previous version:
[https://github.com/lignixz/xra9](https://github.com/lignixz/xra9) . The
prototype is not optimized for performance so excuse that. It is functional to
some extent, if you can figure how to use it. You can add and modify
programming elements.

Would welcome any opinions/feedback. Also interested in finding
partners/investors/sponsors that may be interested in this project.

~~~
worldsayshi
It looks kind of similar to a dream project of my own. It's a project that
I've promised myself to take up on one day. I started building a prototype in
haskell, with front end in Gloss. Tried to get inspiration from functional
reactive programming/modelling.

I thought about using something like a prototype called Hydra (1) as a sort of
runtime for evaluating graphs. Anyway, I really want to get back to it at some
point but other cool things that are slightly more low hanging tends to get in
the way. :)

Another nice inspiration for these things is Ecolanguage (2), not really
programming related but a diagram language for visualizing economic
transactions.

(1) - [https://github.com/giorgidze/Hydra](https://github.com/giorgidze/Hydra)
(2) -
[https://www.youtube.com/watch?v=-QI1iuAvTKE](https://www.youtube.com/watch?v=-QI1iuAvTKE)

~~~
_Robbie
I have been working on a visual programming language for Haskell:
[https://github.com/rgleichman/glance](https://github.com/rgleichman/glance)
Currently, it uses Diagrams and Graphviz to visualize Haskell programs. Please
email me since I think there is a lot we could discuss.

------
hacker_9
There is a couple of reasons. First, VP is essentially just putting code
snippets into nicely coloured boxes, which adds no value apart from making you
have to scroll/zoom more. Additionally the structure of the visual becomes
important, opposed to text which can be infinitely appended to, and so once
you add enough complexity the whole thing becomes complete spaghetti.

VP also hides away a lot of implementation details from you, and assumes the
computer will be able to figure out something better than the programmer. For
example, when would the dropdown run the SQL query? on page load? on drop down
open? As you scale the app bigger, you may want to run a single SQL query and
then chop up the results and hand them out to several dropdowns. If your VP
interface doesn't support this then your done for, but with code there is
always a way.

There is always Clojure of course, which lets you edit your GUI while the app
is running, and upload code changes without having to rebuild, allowing you to
tweak stuff as you go. REPL driven development is great as it gives you both
the flexibility of written code, as well having close to the interactivity
that VP offers.

~~~
phkahler
>> For example, when would the dropdown run the SQL query? on page load? on
drop down open?

You seem to be dancing around what I came to comment on, and that is event
driven programming. It's OK for simple UIs but it tends to break down as
complexity increases.

------
radva42
I've been working on a project that does exactly what you described for the
last few years. IMHO vue.js/react really changed the game here, especially for
CRUD apps.

For example what I did was to code a server part in golang and use vue.js on
the frontend and for the app builder. Using the web-based app builder (also
100% vue) the user can design forms. The forms are stored as serialized JSON
in the database and the server renders dynamically vue.js components. It's
super fast. And there's a complete freedom to design any form with a 16-column
responsive grids and a lot of widgets and styling options. Forms are also
nestable (thanks vue!) and completely extendable with custom JS code so it's
possible to create a custom widget and then simply import it in other parts of
the app.

As I said I think the shadow DOM and frameworks like vue really made the
difference. I started without using such frameworks and it was not only
tedious, but the resulting app wasn't very interactive and felt like a
customized Excel spreadsheet attached on top of a PostgreSQL database. Now
it's a completely different story - it's easy to build fully reactive apps
that feel like a "normal" cloud app and are actually pleasant to use. Of
course instead of spending few months designing and building it, it was
created in a few hours.

So yeah... I think that drag-n-drop builders are definitely coming and will
probably eliminate the need to write such apps in coming years.

~~~
dvdhsu
That's cool -- you should share a link! I've actually also been working on
something just like this, which is why I asked for feedback with this. I'll
post it on HN tomorrow via a Show HN so we can compare!

For anybody interested -- email is in profile. Happy to give you a sneak peek!

~~~
radva42
Awesome, looking forward for your post on ShowHN!

------
phantom_package
I really enjoy Unreal's Blueprints. I program in a text-based language for
work, so it's fun for me to go home and be able to hack on a game without
having to spend more hours staring at text on a screen.

A big difference that I've noticed is that in a visual scripting language, the
"nodes" in the graph can change their shape/color/layout/etc based on what
type of node they are. I love this. With blueprints, if I'm putting together a
material and I put in a color node, a color picker shows up. If I put in a
TextureSample node, a little picture of the texture shows up. In a text-based
language, every variable is just a string of characters - if you want to be
able to tell at a glance what type of object a variable contains, you need to
adopt some kind of a naming convention (or use an IDE that highlights them).

Debugging in unreal is also really cool. The "code paths" light up when
activated, so it's really easy to see exactly which branches of code are and
aren't being run - and that's without actually using a debugger. Side note -
it would be awesome if the lines of text in my IDE lit up as they were run.
Also, debugging games is just incredibly fun and sometimes leads to new
mechanics.

I initially thought that organization would be a problem, but it turns out
that you can make functions just like any other programming language, and
encapsulate blueprints inside of them.

There are also some things that I don't like about Blueprints. Typecasting
usually involves an extra node which feels verbose. If/thens are handled with
a "Branch" node, which again feels verbose.

------
jstewartmobile
I guess it depends on what one considers to be programming. For certain DSLs
(audio, control systems, UIs), it seems to be doing OK. For general-purpose
work, I think they will always be less desirable than text. Even after
thousands of years, words are still our most powerful tool for recording and
sharing new ideas.

Alan Kay's mistake is that a lot of his original work was with Papert on
educating children. For early learning, having a visual/physical analog adds
value. For professional work, when you already have the concepts down, it just
gets in the way.

~~~
ChristianGeek
It's like the difference between a kid's picture book and an adult novel.

~~~
pavlov
I feel this comment significantly devalues graphic novels. It's a separate art
from the novel, but not an inferior one. Pictures have value for adults too.

------
edejong
Things that are difficult in visual languages:

\- Humans are centered around linear communication. Spoken language is
essentially linear, with good use of a stack of concepts. This story-telling
mode maps better on a linear, textual representation than on a graphical
representation. When provided with a graph, it is difficult to find the start
and end. Humans think in graphs, but communicate linearly.

\- Graphs are rather hard to manipulate. You invariably need a mouse, which is
a rather slow instrument. Using keyboard combo's is certainly possible, but is
difficult to make intuitive.

\- A textual representation can be left in a syntactical incoherent position
while editing. For example, I can have non-matching braces. This proves very
helpful in quickly editing code. Visual programming paradigms generally
require a coherent structure, in order to keep them editable.

\- UI builders are extremely valuable, but this is technically not visual
programming. UI builders have problems as well. Complex UIs are often
parameterised (the fields themselves are variable). By offering a visual
context and a textual context, the coding experience can become incoherent and
more difficult to learn.

\- Programming is very context dependant. A programmer focusses on a specific
part, mentally forming a high-dimensional representation of the algorithm at
hand and the larger context. Using a visual representation possibly competes
with the mental map. Also, it forces upon the reader a scoping.

------
david927
I disagree with several here: The problem is that we still program in text,
and that's deeply sub-optimal.* Once we move to programming in data, visual
programming becomes both natural and intuitive, much like data visualization.

In other words, VP itself is a red herring. The leap that needs to first to be
made is that from text to data.

*[https://www.emaze.com/@AWOCZQLL/Text-is-for-Novels](https://www.emaze.com/@AWOCZQLL/Text-is-for-Novels)

~~~
icebraining
That's the claim, but where's the evidence? Is there any implementation that
can show us that?

~~~
david927
It will come. Nothing today. The leap that needs to be made is actually in the
data structures themselves but I understand your skepticism until it arrives.

------
cageface
It doesn't suck if your code involves complex flows of relatively simple data.
Programs like Reaktor and Max MSP have been hugely successful for this kind of
coding in the music world.

If your data structures are more complex and require more convoluted logic,
which is more often the case than not, then the benefits of visual programming
diminish and the downsides are much more apparent.

~~~
flor1s
I've seen a research lab in Tokyo use Max MSP for controlling the motion of a
humanoid robot (using pneumatic actuators). I believe that whenever there is
some flow involved it is easier to model it graphically than textually.

------
throwaway_c
VB6 and (especially) Delphi continue to have many fans. Sadly, there is little
effort seemingly being expended in simplifying programming for normal people,
so a lot of modern visual environments just haven't taken off, which further
reduces incentives for investment in the field, and leads to them being
(correctly) perceived as crippled and unsound.

Also high-mean IQ dev outfits are likely to produce tools for people like
themselves. "Cognitive empathy" is not going to be a strong point for the
framework creators at Google or Facebook. Microsoft seems to have quietly
abandoned Lightswitch, which was their last high-profile attempt in this
space.

Finally market forces mean that working developers have no incentive to adopt
simpler technologies, so there is no pressure on vendors to simplify things
either.

------
vendiddy
One size does not fit all.

UI creation is best handled by a WYSIWYG editor, animations are nice to
visualize on a timeline, and math formulas are clearest when written as is.

Picking the wrong model creates a mess. Try to express a sorting algorithm as
a flowchart. It would be too difficult to follow. Yet a business process is
great to model as a flowchart. A picture is only sometimes worth a thousand
words.

Take a look at the papers published from VPRI, the research org founded by
Alan Kay. They have built languages for graphics, parsing, stream processing--
each optimized for its particular domain. They could have used a general
purpose language but it would have resulted in much more code than necessary.

So the question everyone should be asking is: why hasn't a multi-paradigm
programming environment taken off?

~~~
flukus
> UI creation best handled by a WYSIWYG editor, a business process is best
> modeled as a flowchart

I disagree with those two. UI creation has generally evolved away from
WYSIWYG, composing a UI with code is a much better approach and is now nearly
the universal way of doing it. For the business process, the flow chart only
works as an extremely high level overview, the implementation is always done
in something like code.

~~~
vendiddy
> composing a UI with code is a much better approach and is now nearly the
> universal way of doing it

Why is it a better approach? Universal does not always mean better. Javascript
was built in 10 days and it's now universal.

> the flow chart only works as an extremely high level overview, the
> implementation is always done in something like code

I agree here. The core point I am trying to make is that one size doesn't fit
all and we have to mix and match approaches based on the problem.

~~~
flukus
> Why is it a better approach? Universal does not always mean better.
> Javascript was built in 10 days and it's now universal.

Easier to diff, easier to copy paste, easier to upgrade and easier to extend.
In the 90's we had both approaches and it was the code based (Qt, GTK) and
declarative (html, xaml) systems that (mostly) won.

If I'm working with win32 or winforms then I love the UI designer, but that's
because they come with an awful API, for anything else I'll take the code
approach.

------
mschaef
For me at least, graphical programming tended to crank code style issues up to
11. If you think linear text code formatting is bad, laying out a flow graph
on the screen is worse. If you think naming a function is bad, try drawing an
icon to represent that function. (Or each function in a library of ten or
twenty related functions... )

Graphical programming also walks away from a huge body of work dedicated to
managing, searching, and manipulating text. As good as the graphical tools can
be, there's nothing like all the work that's gone into text editors, diff
tools, query languages, etc. These are all things that are central parts of my
programming workflow, and they are all missing or considerably weaker in a
graphical language. (This is not to mention the fact that graphical
programming gives up two hands and ten fingers as input devices in favor of
one hand pointing and clicking with a mouse.)

I think as appealing as the idea is, whatever benefits there are don't
outweigh the considerable costs.

------
jerf
Programming languages (and a lot of other things) have essential and
accidental complexity:
[https://en.wikipedia.org/wiki/No_Silver_Bullet?wprov=sfla1](https://en.wikipedia.org/wiki/No_Silver_Bullet?wprov=sfla1)

Progress in programming is in removing the accidental complexity to get to the
essential.

In the vast majority of domains, visual programming injects huge amounts of
accidental complexity utterly irrelevant to the domain. So it isn't really
surprising that despite it's superficially appealing elevator pitch and
uniquely pretty demos, it doesn't appeal over the long term.

The domains where it works are those where the complexity is limited, or where
the usually-accidental complexity is actually fundamental... for instance, in
circuit layout the usually-accidental issues involved with layout actually
correspond to something.

Visual programming is firmly established in some nights, and I expect it to
stay in them indefinitely.

------
wruza
What really annoys me in text programming is that I have to write constructs
again and again, referring to manual for method names constantly. Completions
may be smart typewise, but IDEs never assume _what_ I am writing. Let's take a
function:

    
    
      static string defaultFamily = "Sans";
    
      bool
      foo(string s, Alignment a, int height)
      {
        Par_
    

Okay, it began. What can be done with all the available values? Seems that I'm
going to create a paragraph and fill it with some arguments. One of
autocompletion suggestions:

    
    
      bool
      foo(string s, Alignment a, int height)
      {
        Font f(defaultFamily, height);
        if (!f.isValid()) return false;
    
        Paragraph p;
    
        p.setAlignment(a);
        p.setText(s);
        p.setFont(f);
    
        <#rest#>_
    
        return true;
      }
    

How is it obvious? Because Paragraph told the completion system that it needs
at least font and text values set. Height goes to font, other arguments go to
paragraph. Names are selected from the style around. Since we return a boolean
and few objects can be invalid after initialization, it assumes that it is a
status. p is local, so there is something to be done with it, and another <?>
block is created.

Even better, you could just throw items together and get the result:

    
    
      // this->points is double[20];
    
      {
        frame inset 0.5 red stroke;
        add points black stroke;
      ---
      {
        Rect r = this.frame();
        r.inset(0.5, 0.5);
    
        Painter p;
        p.setColor(Color::red());
        p.addPath(rect);
        p.stroke();
    
        p.clearPath();
        for (point in points) {
          p.addPoint(point);
        }
        p.setColor(Color::black());
        p.stroke();
    

But the completion style that we have everywhere just sucks:

    
    
      int
      foo(string s, Alignment a, int height)
      {
        ParadoxDatabaseProvider_
        ParadoxDatabase...
        ...
        Paragraph
        ParamsManager
    

I can't point to good visual programming tool, but our "powerful" text IDEs
are simply prehistorik typewriters.

~~~
Too
> Because Paragraph told the completion system that it needs at least font and
> text values set.

If the class needs at least all those arguments it shouldn't have an empty
constructor. It should have those as arguments to the constructor and then
most good ide today would be able to help you at least a bit better. Have you
tried intellij? Boolean return values without context is also an antipattern,
how am I supposed to know whether true means success or fail or something
else? There is no way any AI would be able to infer that either without
annoyingly amount of false positives.

~~~
wruza
Okay, "paragraph told that non-default font is often used and empty text is
not very useful". These are just examples, I'm not pretending this to be final
form. How about non-construction?

    
    
      foo(string s, string p)
      {
        fin
      ---
        int i = s.find(p);
        if (i < 0) <#?#>;
        _
    

Also, if it appended { on if-line when I press Tab, that would be great.

>There is no way

Really? I clearly see how to do this without any sort of AI. That's graph path
weighting problem based on key words. If it gives you a false positive, just
add words (or put more useful hints and >> _use case snippets_ << if you're
library writer).

But I got your point, let's walk on the same rakes for life. There was a time
when I was amazed by programming, now after two decades I'm tired of it to
death (and yes, it seems that I'm "10x" from the feedback around). Programmers
create and solve problems that mere mortal cannot even understand and this
cool process is far from "cheap". Everyone talks about no-brain easy
programming, but no real steps are done in this way. You know, when you're
doing something often and for years, you just get used to it, know it all, and
see no need for a change, forgetting the learning curve. You can write all of
above snippets with closed eyes. The same happens to the entire profession --
you are professional and that's your value. We doomed to raise professionals
again and again. In what areas? C++, SQL, etc... But wait, these are no areas!
Areas are: medicine, building, etc. I don't want "cee pulse" programmer, I
want a guy who understands my area.

I'm attributing these "no need for this" attitudes to the simple fact that
such a system would be first step to programming without paying a programmer
who solves non-existing problems. You simply put words and the system analyzes
best practices and use cases from selected github projects or templates to
produce a result, and you only need 0.1 of your development forces.
Professional experience is bound to a programmer, but this thing would allow
to change that. The same friction we seen when computers appeared. People
hated them simply because their professions ceased to exist.

Lyrics off, software libraries are graphs. And graph is a thing that can be
processed, if not in generic, then in specific way. There _is_ algorithm that
produces the most wanted result for known specific case.

------
Edmond
I don't think it is the paradigm that sucks but the existing
implementations...it is a hard design problem to solve. No one has quite
figured out the right approach....often the existing implementations make you
click and fill out enough fields to make the entire exercise much worse than
just coding something up in a text editor.

I believe the solution lies in coming up with a way to compose pre-built
components into complete applications...I think the existing efforts involving
Angular,React,VueJS,Vaadin..etc are all pointing in the right direction....I
have been working on Solvent (www.crudzilla.com) for sometime now and solving
the UI building (drag-drop) is something that I am still actively thinking
about...one of these days someone will crack the problem :)

~~~
djedr
> I don't think it is the paradigm that sucks but the existing
> implementations...it is a hard design problem to solve. No one has quite
> figured out the right approach....often the existing implementations make
> you click and fill out enough fields to make the entire exercise much worse
> than just coding something up in a text editor.

True. That's why a proper visual programming environment should build on
existing text-based environments and offer the same capabilities while adding
power. Not disregard all progress, conventions, and achievements and start
form scratch offering some unique features, but at the same time taking away
stuff that's already been figured out.

~~~
Edmond
Agreed, that is more or less the approach I have taken with Solvent...it has a
familiar IDE environment with the additional visual layer on top of it.

------
antaviana
I think that Delphi nailed Visual Programming. It has a mix of speed and
convenience that I do not find in other Visual environments. The fact that
Pascal compiles so fast also helps with the instant gratification when
prototyping an application.

The downside is perhaps that this very same instant gratification makes you
very prone to add business logic in the UI, and it the application sticks
around, you eventually want to refactor the whole thing.

------
FrankyHollywood
Picture says it all: [http://thedailywtf.com/articles/Labview-
Spaghetti](http://thedailywtf.com/articles/Labview-Spaghetti) :)

~~~
nikofeyn
i program in labview daily, and it's always a little disappointing to see this
same dumb picture posted all the time in reference to labview and visual
programming. NO respectable labview programmer would work like that. you could
make the same argument for text-based languages as well, as i have seen some
atrociously formatted code in addition to poorly structured code.

one of the main issues with labview is that people simply don't take it
seriously as a programming language. if people watched how i work everyday, i
work just the same as, if not more efficient than, a good text-based
programmer.

~~~
stinos
_it 's always a little disappointing to see this same dumb picture posted all
the time in reference to labview_

Yup. It's not unlike the -insert whatever language here (C++ being a good
choice)-haters ranting but not actually having used it a lot, or at all.

Moreover: depending on the type of UI, I don't think there is _any_ language
out there which can get me the results I need as fast, when I need something
'process control'-like, i.e. lot of display of e.g. electrical signals and a
bunch of control buttons/textboxes/comboboxes. Then there is just no match for
Labview. And I have quite some experience with writing UIs in
WinForms/WPF/Qt... (typical example: good luck writing a pannable, zoomable,
cursor-able live multisignal 2D graph in any of those - with labview you just
feed data into the premade component and you're done) It even goes so far that
even though the backend is in C++ or Python, I might take the overhead of
writing IPC between backend and Labview frontend over doing the UI in the
backend language.

------
nickbauman
The old "Gold Standard" for WYSIWYG programming has been Apple's Interface
Builder. But every iOS dev I know has moved entirely away from IB in favor of
programatic construction of the UI (in Swift or Objective-C text). Why?
Because they want to have automated tests over everything they can.

The simpler way to say this is: "Complex ideas can only really precisely be
expressed in text. To the degree you can express them visually is to the
degree that there are expressed as complex text underneath."

~~~
jononor
Can't one test a layout built with IB? Load it in a unit test for instance?

------
petra
One modern incarnation of visual programming is called "low code", and it
seems pretty successful.

This is a good introduction and discussion about whether this is a fad or it's
here to stay: [https://medium.com/softwareimprovementgroup/low-code-wave-
of...](https://medium.com/softwareimprovementgroup/low-code-wave-of-the-
future-or-blast-from-the-past-7fcd618371b2)

~~~
bcherny
Looking at the website [0], this is a joke right? Flashy marketing business
speak sales site with charts, but what does the product look like?

[0] [http://low-code.com](http://low-code.com)

~~~
petra
You're kidding, right ? that's a really low effort search :)

Anyway, i gave a link above, with good info, including names of leading
companies. Here's one:

[https://www.mendix.com/](https://www.mendix.com/)

~~~
dalacv
Also , outsystems and bubble.is, oracle Apex

------
lithos
It doesn't. The electrical world has been using contactor diagrams for complex
logic for decades, and with the inclusion of more advanced computer components
ladder logic (still the same concepts, symbols and logic)

[https://www.allaboutcircuits.com/worksheets/ac-motor-
control...](https://www.allaboutcircuits.com/worksheets/ac-motor-control-
circuits/) is the link I quickly found.

It's typical to see a handful of symbols handle what would take a hundred of
lines of code for the level of user interface usability, validation, and core
functionality.

~~~
Qantourisc
Difference here is, we are using humans to fill in the gaps. With visual
programming, we either still have to draw the exact wire-diagrams, or exactly
define the function of a symbol.

~~~
lithos
Quite a few PLCs have ladder logic as a programming language as a selling
point.

For physical systems it is pretty true.

------
overgard
I think this is a minority perspective, but I generally think coding has a lot
more in common with writing than it does with engineering. (I guess Literate
Programming would sort of support this idea). Can you imagine trying to write
an essay as a flowchart? I think it would just obscure the point, rather than
simplify it.

~~~
indigochill
Structurally, a program is also similar to music. A program, if we view the
bytecode, is read linearly by default but may have jumps at certain points
forwards or backwards, like a coda in musical notation.

~~~
jononor
People make amazingly complex music in Digital Audio Workstations. Personally
I think there is some inspiration to draw from their use/function into the
programming experience.

------
adpoe
Personally, I think that written language is a more natural way to describe
and reason about complex systems and symbols.

It's the same difference between writing mathematical proofs as systems of
equations vs. proof by drawing a diagram, or making a visualization.

Proofs can be written using both methods, but if you have a strong command of
the written/symbolic vocabulary, it is faster and more succinct.

Put another way: I can describe the landscape of a lush, green Tuscan
Countryside--with rolling hills, morning dew, and and crisp feeling of the
first rays of sun cutting through the mist--in just a few lines. You get a
picture in your head, and it is likely very similar to what was in mine.

Imagine now, that we can't use words. We have to draw pictures. It will take
much longer to get the same point across. Language--for certain purposes--is
more efficient, and more information dense.

That's my hypothesis/feeling.

------
analog31
I wonder how many people have physical issues with computer screens. My own
anecdote is that I get severe eyestrain headaches and neck / wrist fatigue,
when I have to do fine manipulation on a computer screen.

I spent a few months using LabVIEW, more than 20 years ago, and it was
physically debilitating. I also have a hard time doing CAD. When I'm typing
code, I'm not really focused on the screen unless I need to be. Sometimes I
close my eyes and type, or look away from the screen.

Another thought about text based languages is that they make it much easier to
create and explore new languages, because you don't need to program a full
blown graphical editor every time, make it work on every platform, etc.
Especially for languages that are supported by volunteers, maintaining
graphical tools might not be the best allocation of effort.

------
smilesnd
Unreal has a VPL and it is a pain to use. A simple piece of code takes up so
much desktop real estate that you either have to slowly move around to see it
all or have to add more monitors to your setup to see it all. You think
spaghetti code is bad imagine actually having a visual representation of it
you have to work with. Organization doesn't exist you can go left, up, right,
or down. If you ever try to enforce coding standards think about adding x and
y coordinations and other location standards. Finally I could only imagine the
black magic that goes along with such a thing. Visual studio black magic is
already horrible to deal with one little hiccup and you are lucky if all you
have to do is create a new project and migrate your files/folders over to it.

~~~
Stratoscope
For the curious, here is an example of Unreal's Blueprint code:

[https://forums.unrealengine.com/attachment.php?attachmentid=...](https://forums.unrealengine.com/attachment.php?attachmentid=116071&d=1478103220)

------
amatheus
Visual programming is used in Maya or Houdini for example (I think Houdini is
more oriented towards it). While these are 3D software, I don't think there's
anything 3D specific about how it works. I've seen a video of a guy showing
how to create assets for game and building something that works pretty much as
a function out of interconnected nodes (I can't remember the exact webinar I
watched but found this other
[https://vimeo.com/202120820](https://vimeo.com/202120820)). Now they don't
call it programming but as I see it, that's programming and the basic idea
could be made to work in other contexts.

------
mabynogy
Because of the Deutsh limit:
[https://en.wikipedia.org/wiki/Deutsch_limit](https://en.wikipedia.org/wiki/Deutsch_limit)

~~~
jpm_sd
That's like saying it's impossible to design a motherboard because you can't
show all the bypass capacitors on the top level schematic. Hierarchical design
and layers of abstraction are vital in both hardware and software.

~~~
BevanR
True; but visual programming means you need more 2D space (screen) to see the
same amount of logic. Maybe with bigger screens it could work better?

------
richard_shelton
I think the truth is somewhere in the middle. Look at complex CAD systems and
editors. They focused on the visual side and still provide some kind of
command line for scripting the things. Even in pure visual programming systems
like PD you can type algebraic expressions in textual form. And in text-based
systems you may have lots of 2d tables (Smalltalk), graphs of modules,
semantic colors (colorForth) etc.

Imagine GUI editor where the user can type the code on the left side and also
can move and edit widgets with cursor on the right side. And editing of both
sides is working in live mode. My point is that we need to have the best of
both worlds to be really productive.

~~~
djedr
> I think the truth is somewhere in the middle.

Totally agree. I think the major reason visual programming sucks is exactly
because some things which are simple to do using text-based programming become
way harder when all you can do is drag graphs around.

On the other hand, some things are easier and more intuitive when represented
and manipulated visually using graphs or trees.

I think that a visual programming environment which would be an extension of a
text-based programming environment, in that you could do everything that you
can do in IDEs everybody is already used to PLUS the cool stuff you can do
with visual programming, would have high chances of not sucking.

> Imagine GUI editor where the user can type the code on the left side and
> also can move and edit widgets with cursor on the right side. And editing of
> both sides is working in live mode. My point is that we need to have the
> best of both worlds to be really productive.

I made a hybrid visual and text programming language and prototype development
environment for it as a project for my master's thesis [0].

The main idea was very similar to what you are imagining. Textual code on the
left side and visual representation on the right [1]. You can edit one and
have the changes reflected dynamically in the other.

Actually my idea was even more general and could be extended to parallel-
editing multiple representation of the same syntax tree.

I would love have the time to explore this stuff some more.

[0]
[http://djedr.github.io/masters_thesis.pdf](http://djedr.github.io/masters_thesis.pdf)

[1] [http://djedr.github.io/gfx/masters-thesis/ide-
prototype.png](http://djedr.github.io/gfx/masters-thesis/ide-prototype.png)

------
pishpash
For event-driven programming like what you describe, Visual Basic worked fine.
Too bad that kind of very efficient UI building got thrown out irrationally
with the hate for Visual Basic the language.

~~~
meredydd
Obligatory plug: We're bringing it back!

Check out [https://anvil.works](https://anvil.works) \- it's like VB, only for
this century (the web) and using a sensible language (Python, both client and
server).

We just took it to PyCon, and the reaction was pretty gratifying :)

------
dgudkov
I believe general purpose visual programming hasn't become widely popular
because currently it's not really needed for general programming. General
programming used to be pretty low-level (e.g. i++) and linear (because it's
single-threaded in vast majority of cases). Things slowly change though. Now
popular functional programming tends to be more high-level and the shift to
multi-core CPUs even on mobile devices encourages more and more developers
write multi-threaded code.

At the same time there are very successful niche cases for visual programming
with Excel as the most prominent. Yes, there are no data flows in Excel
(although it can display dependencies with arrows), but you typically can
easily identify visual blocks (chains) of calculations on a sheet. I've
designed a visual programming tool for data transformation
([http://easymorph.com](http://easymorph.com)) which can be viewed as a visual
programming language[1] because typically the task of data transformation is
high-level and non-linear, and visual programming works very well in this
case.

[1] [http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-
fun...](http://bi-review.blogspot.ca/2015/06/easymorph-as-visual-
functional.html)

~~~
jononor
The common pattern of applying the same macro to each of the rows/columns can
be seen as a SIMD/vectorized operation with the affected cells as inputs and
outputs.

------
xaduha
I can tell you where in my opinion visual programming works (or can work if
anyone actually bothered), but you probably not gonna like it.

First step is to think about IDE assisted programming as a proto visual
programming. Second step is to have a real DSL, not just some general purpose
programming language with some extra words sprinkled that sort of look like a
DSL, but you can easily escape. Visual programming tools that aims to do the
job of general purpose programming language is kinda doomed from the start in
my opinion.

Here's a snag - how many DSL languages do you know that have intelligent IDE
support? Designing a good DSL language is kinda hard in the first place. I
know of many, but they are called XML languages, deal-breaker for many. XProc
can work as an underlying language for such a visual programming tool, with a
good XML schema enabled IDE or editor such as OxygenXML you won't even work
with XML as most see it, it's not really text anymore. Dropdown menus in a
representation of a tree, that's what it becomes.

There were at least two attempts to create an actual visual programming tool
on the base of XProc, most advanced was this one
[https://community.emc.com/docs/DOC-4382](https://community.emc.com/docs/DOC-4382)

~~~
jononor
Embedded DSLs (using the general purpose programming language as the host) is
the way to go for an integrated workflow/experience. I think the same is the
case for visual programming languages/tools.

------
mafribe
Graydon Hoare (Rust creator) has an interesting post on a related matter
"always bet on text"
[http://graydon.livejournal.com/196162.html](http://graydon.livejournal.com/196162.html)

~~~
trevyn
I deeply enjoy how this post uses images to illustrate its points. :)

------
lisper
> The type of visual programming I'm thinking about here is a WYSIWYG drag and
> drop interface for building UIs.

The main challenge in this particular domain is describing what is supposed to
happen to the layout when the size of the window changes, or if there are
dependencies among visual elements (e.g. some element only appears when a
check box is checked). When laying things out visually you can only ever
design one particular instance of a layout. If all your elements are static,
this works just fine. But if the layout is in any way dynamic (with window
resizing being the most common case) you now have to either describe what you
want to have happen when things change, or have the system guess. And there
are a lot of options: scaling, cropping, letterboxing, overflowing, "smart"
reflow... The possibilities are endless, so describing all of that complexity
in general requires a full programming language. This is one the reasons that
even CSS can be very frustrating, and people often resort to Javascript to get
their UI to do the Right Thing.

~~~
worldsayshi
Yes there are a lot of options but I don't think that it would be
inconceivable to have such options split out as separate components.

I want an hide-overflow behavior to this component, then I just wrap it with a
hide-overflow component. Doing that drag-and-drop should work. Then again you
would need to design such components in a way that makes them intuitive to
use, but that's always the case.

------
flohofwoe
Programming through typing text has already become 'visual programming', just
from an unexpected direction: syntax highlighting, compile error checking
while you type, code completion, fuzzy searching, argument type popups and so
on. The only thing that's missing is better debugging integration (essentially
show how the program state changes while you type).

~~~
skibz
Your comment is definitely an interesting take on the question. I would argue,
however, that integrated debugging in the way you describe (along with the
various programming text editor features) is what constitutes a live
programming environment.

------
nacc
I think it really depends on the task. We are just hijacking the brain
machinery to do jobs it is not evolved to deal with. If we can find some
highly evolved / optimized brain function which reflects the structure of the
new job, the brain can process it much more efficiently.

Text might be good for programming because, most of the programming are
sequential, text is sequential, and text processing is highly optimized in the
brain because language. But in fact, we also use a bit of visual programming
(indentation, paragraphs) in text to reflect part of the program structure
that are not sequential.

If the program is completely non-sequential, visual tools which reflects the
structure of the program are going to be much better than text. For example,
if you are designing a electronic circuit, you draw a circuit diagram.
Describing a electronic circuit purely in text is not going to be very
helpful.

------
thenanyu
My pet theory: Code is N-dimensional - every set of braces, every nested
function call, increases the execution by a dimension and humans are really
only good at visualizing in 2 or 3 dimensions. Specific domains that are
constrained to 2-3 dimensions are suitable for visual programming, but it's
hard to generalize.

------
jensgk
Always bet on text:
[https://news.ycombinator.com/item?id=8451271](https://news.ycombinator.com/item?id=8451271)

~~~
egfx
True 3 years ago but 3 years from now? Maybe not.

------
dev4people
I think that Visual Programming could be more suitable for building modern
applications that may need to make web services to monitor physical devices
(for example) or to gather and analyze values coming from sensors,etc...
That's exactly what has driven the design or our new Visual Programming
language : the need of being able to rapidly and easily build applications
that connect and use technologies that were not made for working together
([https://www.youtube.com/watch?v=uRWIlDXeLdk](https://www.youtube.com/watch?v=uRWIlDXeLdk)
and
[https://www.youtube.com/watch?v=JccLWZ6nPlY](https://www.youtube.com/watch?v=JccLWZ6nPlY)).
(Full disclosure, CEO of Hackeet)

------
pshc
I'd like to share some thoughts:

\- Visual programming tools usually only work at one abstraction level (your
first point)

\- Often centered around a gimmick and cannot encode "normal" detail-oriented
imperative code efficiently

\- Only a fraction of a given program is amenable to flow charts, Visual
Basic-style forms, etc. Unfortunately, most visual programming environments
are all-encompassing.

\- So VPs tend to become blunt, awkward tools that lack power of expression,
ergonomic editors, scalability to real usecases, etc.

FWIW, I do believe that a better code editor is possible through non-plaintext
programming. (Serialize token trees and ASTs, instead of plaintext.) But such
an editor would likely be used in text-editor-mode >50% of the time, just due
to the high information content and sheer readability of text.

~~~
meredydd
_> I do believe that a better code editor is possible through non-plaintext
programming. (Serialize token trees and ASTs, instead of plaintext.)_

Funnily enough, this is itself another of those mirages, like visual
programming, that have been chased for years and failed to gain traction
(outside specialised applications).

For my money, the reason for this is that a human editing code needs to write
something invalid - on your way from Valid Program A to Valid Program B, you
will temporarily write Invalid Jumble Of Bytes X. If your editor tries to
prevent you writing invalid jumbles of bytes, you will be fighting it
constantly.

The only languages with widely-used AST-based editing is the Lisp family (with
paredit). They get away with this because:

1\. Lisp 'syntax' is so low-level that it doesn't constrain your (invalid)
intermediate states much. (ie you can still write a (let) or (cond) with the
wrong number of arguments while you're thinking).

2\. Paredit modes always have an "escape hatch" for editing text directly (eg
you can usually highlight and delete an unbalanced parenthesis). You don't
need it often (see #1) - but when you need it, you _really_ need it.

~~~
pshc
I've been thinking along the same lines. The "fighting your editor" problem
cannot be ignored, and it's common in VPs. Real programming code needs "jank".
We need to be able to move between different states:

Bags of characters <-> Unstructured trees of tokens <-> ASTs

(BTW paredit is super cool and I'd like to see more of its kind!)

~~~
meredydd
Thing is, the architecture you just described _is_ a modern IDE with
refactoring etc.

This is a well-trodden road. It starts with "wouldn't it be awesome if we
could manipulate everything as ASTs", then usability intervenes and we fall
back to "well, we need to be able to selectively edit as text", which means
you need to be able to convert everything to bags of characters and back. And
now you've built that conversion, you might as well represent the "source of
truth" as bags of characters like everyone else does.

~~~
pshc
I agree with what you're saying, except the last part. Using ASTs as the
source of truth (embedded in a source control forest) has benefits that are
worth the difficulty.

~~~
meredydd
What's the benefit? If your tooling already requires lossless round-trips to
and from text, why invent a funky storage format that doesn't interoperate and
can't be fixed with a text editor when it all blows up? You already have a
perfect serialisation of the AST, in a format every other tool understands -
that is, source code.

(And heaven forbid you should want to make a checkpoint commit that doesn't
parse...)

~~~
pshc
Some potential use cases:

\- Using Merkle trees, we can assign every node a hash-based ID. So now we can
refer to other nodes by ID. This lets us store a graph whose vertices are all
the tree nodes.

\- With the graph, we can now reference bindings not by string literal, but by
ID. This eliminates shadowing problems and missing imports.

\- There is now one source of truth for the names of variables and functions.
As a result, in source control, a commit that renames something is a one-line
change.

------
dennisgorelik
Visual languages never found a good solution to most of software development
tasks.

For example:

1) How do I view diff between old and new version?

2) How do I search for an element in my visual code?

3) How do I email example of visual code to my colleague?

4) How do I message an example of visual code?

5) How do I blog about visual code?

------
calebh
Nobody here has mentioned language workbench tools, the best of which is
probably Jetbrains MPS:
[https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

These language workbench tools make it easy to switch between graphical and
textual representations. Also you get intelligent IDE support and typechecking
for free.

The primary alternatives to MPS are Xtext and Microsoft's language workbench
(formerly known as Intentional Software, Microsoft just bought them).

------
jmts
I did some work with webMethods Flow in a previous job. I hated it. Aside from
the fact that it was slow from a point-and-click point of view, the interface
was generally slow, and navigation and search were generally tiresome. To my
memory it was not possible to have related flows side-by-side for reference,
and much of it was abstracted to a high enough level simply due to language
features that it was difficult to identify patterns and idioms within a set of
logic at a glance. This also meant that any opportunities for refactoring or
code reuse were few not only because it was difficult to do, but also because
they were difficult to see.

Much of this can probably be improved in the IDE, and it is possible that
there were issues simply because we may have been abusing it (there other
platforms/languages that were being used beyond their original design).

What little I've seen of LabVIEW at my current job suggests that it has a more
usable interface, however having written DLLs to be used by LabVIEW, it still
appears to be quite restrictive at a language design level which I expect
would still limit its usefulness (I hear regular talk of the use of
singletons, users appear to be required to translate a C API to LabVIEW
manually, useful C language features like structs and function pointers don't
appear to have any support, the ability to maintain a reference to a context
pointer gives rise to groaning developers).

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

------
iEchoic
I think it's because some visual mediums are better at representing certain
forms of information than others, and visual programming tools attempt to
represent a form of information (programming logic) using a visual medium
(images) that isn't optimal for that form of information. Analogies can be
made for things like calendars (which are the preferred visual medium for
visualizing schedules), sheet music (which is the preferred visual medium for
visualizing music - though guitar tabs present an interesting alternative to
think about), and movie scripts (for which text is the preferred medium).

In the same way that a movie script is best represented by text, my belief is
that text is superior to images for representing programming logic, and images
are superior to text for representing UI elements. I think most people at
least feel the same about representing UI elements, which is why visual
programming tools are appealing.

This leads to the conclusion that the best tools for building UIs would
represent programming logic in text, and represent UI elements using images.
In my experience, this is true; tools like Unity and Flash are, in my opinion,
better for UI development than HTML/CSS (text). This also leads to the
conclusion that unless someone invents a better way of representing
programming logic than using text - like the equivalent of inventing a
calendar to display a schedule, if we had never invented a calendar before -
visual-only programming is inherently limited.

Tools that keep UI in visual-land and programming logic in text-land - and
don't try to mix the two - work great.

------
eikenberry
Part of the problem might just be that you are ultimately comparing it to
using text for programming and that text just works extremely well for the
vast majority of programming.

------
dragandj
Think ancient Egyptian hieroglyphs or Chineese pictograms. They seem like a
good idea until you need to describe specific nuances. There is a reason
alphabet won.

------
mcphage
That's how Interface Builder on macOS/iOS works, especially in concert with
Key Value Coding and Key Value Binding. It's cool stuff, check it out.

~~~
thebaer
As a fellow mobile developer, I highly prefer Android's non-visual option with
human-readable and -editable XML. I always find myself editing layouts
textually and then just using the visual editor to preview how things look.

Interface Builder was great for me at first, when learning iOS-specific
controls and how everything worked, but as I've gotten better I've found it's
always more of a hindrance. Things really start to break down when you need to
move fully laid-out controls to a new container, for example, whereas
Android's XML layouts let me do that by deleting/changing a few lines of text.

------
badsectoracula
One thing that nobody seems to notice is that big thing in front of you with
the tons of buttons: the keyboard. The main input device we use to enter stuff
in our computers are based on typewriters, so everything more advanced than
clicking widgets with the mouse revolves around typing stuff. Most visual
languages feel like you are fighting with their code editors because the
editors are not following the typewriter model that the main input device of
our computers use.

Perhaps this will change in the future with other input devices, touch devices
like tables could provide for a different environment - currently programming
with a tablet feels slugggish but this is because everything about programming
revolves around typing. Touch is different. But it needs to be designed from
the ground up for the interface you work with.

Whatever that is, i don't think text is the only way to go. I believe our
keyboards have shaped the way we think about programming - and interacting
with computers in general - and if we are to explore other ways to program, we
need to also explore other ways to communicate with the computer.

------
lloydfischer
Way back in a previous life I made a living building a visual programming tool
and language to specify simulations. After many years of work it became clear
that visual programming works very well in industries that already have a well
established visual paradigm. We had great success with simulating hydraulic
systems by letting folks specify them with standard piping and instrumentation
diagrams. The cooling system simulation for the space station simulator ended
up being built that way with our system, as were many simulations of nuclear
power plant cooling systems. However, after you do P&i diagrams and electronic
schematics you very quickly run out of well established visual paradigms. Uml
is just not useful in the way that a piping diagram is.

As to text, a colleague once described the best feature of a text
specification of code was "visual rhyme". You know, when you can look at a
block of code and feel how it ebbs and flows. That's from the old days, I
don't know if functional code rhymes like Fortean did.

------
groundshop
SQL Server Integration Services (SSIS) does a good job of this I think. SSIS
is made for manipulating data flows. The flow of data happens to be very well
represented in many cases by visual network flow diagrams. Most of the common
patterns of data flow are implemented as drag and drop widgets.

That said, as necessary, you can do pretty much anything in that environment
as code if you want. The best thing about the language, though, is that /if/
you go down the path of coding something out instead of using a common
pattern, it forces you to ask "Why am I doing something out of the norm here?"
Sometimes you have a valid reason. Sometimes you don't and that question
course corrects you back into a maintainable architecture. It's a very niche
language (even mostly vendor locked down), but I think it's a great example of
a visual programming environment that's mostly great to work in.

------
simplify
Check out node-red[1], a visual language for creating node apps. It's a good
demonstration of the potential of visual-based languages (but it's also far
from that potential).

[1]
[https://www.youtube.com/watch?v=f5o4tIz2Zzc](https://www.youtube.com/watch?v=f5o4tIz2Zzc)

------
anotheryou
WYSIWYG fails for two reasons:

\- Programming errors most of the time break everything. You probably know how
bitchy Word can be. Errors will be frequent und finding them when you don't
really know what happens under the hood will be very difficult.

\- WYSIWYG does not abstract very well. The big power of programming however
is, that you can build your own tools from a minimal set of building blocks.
Visual representation for self-build tools and routines will not be pretty out
of the box.

\---

Those visual languages that do have a big userbase do the following:

\- no WYSIWYG, just "nodes". The visual parts of the nodes:

\- - inputs and outputs are often connected with "wires"

\- - simple control UI like a knob or a button can be shown directly

\- they allow wrapping a bunch of wired mess in to a box with simple in- and
outputs again

\- some allow to jump back in to code where necessary

\- in general nice for small art-projects

\- difficult or at least in-flexible for complex stuff

\- often a lot more copy+pasting

\---

------
wruza
>Then you interact with their API: this table pulls in data from this SQL
statement; this button executes this HTTP query; this dropdown publishes this
value, which this SQL statement uses via string interpolation. These "widgets"
publish their data, which can be used by other widgets (w1.value), and inside
SQL queries. The tables can pull in data from SQL queries. You can use string
interpolation inside SQL queries, so dropdowns can influence the query being
run. So selecting a drop down value would cause the query to change, which
would automatically propagate changes to the table.

This is very similar to Xcode Cocoa/CoreData bindings, but these are too
restricted to create anything nontrivial. IME I always had to fallback to
delegate and data source methods in source code.

------
ux-app
> Why does visual programming suck?

It doesn't? Shameless plug, I build a visual programming tool for UI design
([https://www.ux-app.com/static/learn-actions-and-events.html](https://www.ux-
app.com/static/learn-actions-and-events.html)).

It's great for a huge subset of people for whom coding is tangential to their
job. Product managers, designers etc.

It's not ideal for a programmer because it's not as dense as the textual
representation and once you've developed that muscle memory, typing your code
is a lot quicker, but increasingly, there are a lot more people coding now who
are not career programmers. For these people visual programming is great since
it's less intimidating and reduces the possibility of syntax errors.

------
sweetPete
The type of visual programming you're suggesting seems to exist in an extreme
form as the apps we use to read and write data, like Facebook, Trello, etc. On
the other end of the spectrum we have the very technical savvy that want more
direct control of what's going on. There's a lot of middle ground that's been
covered, from both ends of the stack. I don't think the idea of visualizing
things to be more material is flawed, but surely you could overdo it or apply
the wrong model at the wrong level of abstraction.

All of our programming is visual.

We rely on a set of visual units of some manageable size (an alphabet of
characters), and then we compose them sequentially into strings (visual units
of a more general alphabet)

Stringing units together makes sense based on the way we experience a limited
bandwidth of signal over time.

While listening, signal is presented one unit of the sequence at a time. When
reading, we are presented with a whole page of characters at a time. The
surrounding area is displayed, and we can move the focus around at will.

This leads to the development of the visualization models/techniques that we
progress from simple features like spaces between words; parentheses/curly
braces to group words; indentation of blocks to group/subordinate them,
forming trees.

The idea of the unit/object/thing, composed of unit/object/things is thematic.

Files are units of text that are read/written one at a time. Eventually you
stop directly typing, and you enter a different level of abstraction, where
the units are displayed and manipulated with a different set of controls.

I think this is the point where the flowchart (directed graph) model fits in
with the text focused model.

In Sublime, I like having the directory outline view and the zoomed-out
scrollbar view with whatever single page of text I'm viewing. I think it'd be
cool if these three were integrated, so that I open and close the files in a
flowchart in the plane, where edges/arrows represent organization and
dependencies. I'd like to import a module by dragging an arrow from one node
to another

------
afpx
But, isn't text just abstract signs and symbols? Why can't we, programmers,
make new or better symbols? Why can't the language be augmented to incorporate
concepts of computing?

I never desired visual programming until recently. I never had the need for
it. Plus, I always found the existing visual languages and tools to be clunky.

But, lately, I often find myself with just my tablet and stylist. And, during
these times, I want to 'sketch' out programs. I have some ideas on how this
would work in practice. There would have to be detection of gestures, and
instant feedback that provides visualization of the changes.

------
m0ther
Your code, as text, serializes structures that change in all sorts of
beautiful ways over time. It's hard to represent that in two dimensions. We
can write about it though, in a language the computer can
interpret/deserialize.

Building a good visual programming environment I'd imagine would require
either having a way to visualize and move around in higher dimensions, or
dumbing down and limiting what can be done to fit neatly in two dimensions.

I like Reaktor Blocks a lot, by native instruments. They took the second
tactic, and the result is beautiful (but limited). For what you use it for, it
works great.

------
mseebach
Programming is _inherently_ difficult. We can do a lot in tooling and
increasingly higher level languages to help make a lot of the details a lot
easier, but a the core, it remains abstract symbolic manipulation.

It seems to me (and I have by no means done an extensive survey of the field,
so YMMV) that efforts in visual programming suffers from mis-diagnosing that
the difficult part of programming is the act of writing the code (indeed, the
empty editor is intimidating and code in any language looks impenetrable to
outsiders), rather than understanding what code to write in the first place.

------
antender
VP isn't a bad idea by itself, but its implementations usually have the same
problems:

1\. It's hard to make a scheme in editor without spaghettifying it. (Partially
mitigated by blocks incapsulating parts of scheme in themself, some discipline
is required)

2\. Usually VP makes it hard to work with complex data structures. The only
solution is to basically write the same code as text losing all VP in the
process.

[http://hiasm.com/](http://hiasm.com/) : Very usable constructor for small
programs, the only problem with it is that website is in russian.

------
dirtyaura
Because language and abstraction goes hand in hand. The great leap 50,000 to
100,000 years ago did something to our brains that brought both our use of
language and capability of our mind to another level.

------
ThomPete
Because it's not optimal for programming. It's however great for scripting.

If you are a good enough programmer you want the power of ex regular
expressions and you can solve almost any problem out there.

If you aren't you aren't much better off as you still need to learn how to
program.

As a scripting language however it can be great because you can be much more
opinionated about what should be prioritized.

What would be much more interesting and useful IMO was if normal languages
created a visual environment akin to the visual programming languages we see
sometimes.

------
rubyfan
I don't know much about how other people think but I'm fairly certain that I
favor auditory mode. When I write code I generally am in auditory mode and
then expressing logic becomes fairly easy with text. Further, I believe
abstractions like classes and objects, etc. tend to favor text/auditory
expression.

Visual programming to me becomes very scattered and fragmented. Bits and
pieces of logic seem to end up all over the place and become hard to keep a
cohesive functionality together.

------
awinter-py
tooling tends to suck, input ends up being slower once you know how to do it.
(Argument to be made that visual is _faster_ on a tablet with no keyboard.
Okay).

You still have to type to name things.

Density of stuff on the screen is lower.

Not sure about readability (you can find readability advantages for any format
if you ask the right person). I would bet math expressions with many terms are
clearer in a visual format like tex.

Visual elides the connection between functions and files/modules, potentially
making it hard to scale projects.

------
gwbas1c
This was an active area of study in the 80s, with many journal publications.
The goal was to make programming intuitive.

Then one day someone published an article explaining that we need words to
represent variables, doing it visually runs out of abstractions too quickly to
do anything useful.

There were no journal publications after.

It's been about 14 years since I last looked at these publications and my
memory is foggy. The point is that any useful program is too complicated to
represent with pictures.

~~~
jononor
In dataflow programming, and some variations of functional programming,
variables are pretty rare.

But I'd be interested in reading the study you refer, do you know how to find
it?

~~~
DonaldFisk
In dataflow programming, variables are unnecessary.

------
empath75
We call visual programming that doesn't suck a 'graphical user interface'.

Look at a daw like Logic or Ableton for example -- it's essentially visual
programming.

------
VladimirGolovin
Filter Forge founder here, now working on a turing-complete functional visual
programming language inspired mostly by Haskell:
[https://imgur.com/a/HkSgJ](https://imgur.com/a/HkSgJ)

Here's what I currently think on visual programming languages:

1\. I see no place for imperative and non-pure functional languages in visual
programming.

2\. Pure functional languages can absolutely be implemented with visual
syntax. This is just another form of representing a program. Instead of taking
text as an input, the compiler / interpreter takes the node-based
representation, which may or may not directly correspond to the AST. Here's an
example of the same toy program in Haskell, Racket and our visual language:
[https://i.imgur.com/dsNJYyx.png](https://i.imgur.com/dsNJYyx.png)

3\. Visual languages shine on higher levels of abstraction. They work great in
Filter Forge and similar systems, e.g. material / shader editors in 3D
packages or game engines. However, I've never seen a visual language that
remains usable and understandable on a lower level of abstraction.

4\. Our civilization has settled on text as the lowest common denominator
format of information exchange. We have accumulated an enormous amount of
tools, infrastructure and software ecosystems built around text. Git, Slack,
WWW, Copy / Paste, Ctrl/CMD + F, diff tools, IDEs, regexps, Unix pipes etc etc
etc. A visual language will have to reinvent all these wheels.

5\. Visual programs have no equivalent of line numbers for addressability. You
can unambiguously refer to a location in a text program with just two numbers,
line & column, but how do you do that in a visual program? "Uh, it's the red
rectangular block with the blue output, to the left of the square green one.
The connection you need is the second from the top."?

6\. I see no way of quickly commenting out / deactivating a section of a
visual program.

7\. When you write a text program, you are compelled to give descriptive names
to things like functions and variables. A visual program doesn't force you to
do that. For example, in our language you connect function outputs to function
inputs with graphical arrows, and named binds aren't necessary. In Haskell,
however, if you don't want your program to look as a huge chain of function
applications, you bind results of certain function to named 'variables', and
the names tend to be human-friendly (well, at least in monomorphic functions).
To sum up, visual languages lack built-in annotatability and don't compel
programmers to annotate programs. Annotation feels extraneous, tacked-on.

8\. I/O is hard. Sure, it can be done the Haskell way, but without some kind
of monadic sugar (somehow adapted to a visual language) it would be absolutely
unpalatable. Also, this would only work on visual languages that are capable
of expressing a monad.

~~~
vlaaad
Wow, I really like it!

Although, I think your ui is too verbose. Main indicator, is, well, the size
of "blocks of data", where text takes 4 times less space than visual
representation. But there is also an information overload: text representation
of `map` call has no indication of what kind of arguments it expects, it is
implied by order of args and basically is just defined by language. I guess,
visual analog of this code should follow the same trope: it should strip type
annotations (which probably should be available VP IDE with a shortcut), and
imply meaning of args (maybe with colors?)

~~~
VladimirGolovin
Agreed on verbosity. That's one of the reasons why I think that visual
languages don't work well on lower levels of abstraction.

(BTW, texts in the Map call are argument names, and colors indicate their
type.)

------
tyingq
Google's app maker talks a good game. Haven't been able to try it yet.
Supposedly, you are able to script pretty freely on both the front and back
end for situations where the canned functionality isn't suitable.
[https://developers.google.com/appmaker/](https://developers.google.com/appmaker/)

------
kilon
Every time a VPL (Visual Programming Language) has gone against a TPL (text
programming language) , VPL not only has come out a winner it has massacred
its opponent.

There are 3 areas that I am aware of that VPLs have appeared a) modular audio
synthesis b) 3d graphics c) game programming

(a) has been the first with origins back to 1995 , there are like a ton of
programming apis for building modular synthesizers , there even programming
languages that specialize in this that have existed for decades now like
CSOUND and Supercolider but Reaktor and Max/MSP have literally mopolised the
market. Reaktor itself has been such a massive success that made Native
Instrument as the dominant company on audio software.

(b) 3d graphics is no secret that is probably the richest software industry
with the generation of the well knows CGI for films and games its a goldmine
for developers and has been dominated by VPLs. You are not aware of this most
likely because we never refer to them as VPL but rather as procedural
material, textures, animation etc. Not using a VPL for todays standards is
considered insane even if you try to do it via a very lovable language like
Python. Text languages like POV RAY that specialize in 3d graphics have died a
miserable death. 3d is where TPLs go to die and are used strictly for
generating the software alone and thats about it.

(c) computer games there VPLs are something new but Unreal has definitely
changed that with Blueprints. Probably the best and most powerful VPL. If you
have played any kind of AAA game chances are that the game you played uses
Unreal which in turn makes heavy usage of Blueprints and C++ code. The rule of
thumb among Unreal developers is "Do it with Blueprint and if you cannot avoid
it do it with C++". Unity has smelled the roses and has implement its own VPL
as well very similar to Blueprints.

So if VPLs are so amazing why we do not see more of them ? They are actually
very hard to make. If an implementation of lisp , a basic one, needs a few
hundreds lines of code a VPL needs thousands and that imposes a high barrier
for language designers. Hence why we have thousands of TPL and only a handful
of VPLs.

The majority of them are crappy obviously because that is how quality works ,
you have to have high quantity for high quality.

But a high quality VPL will kick high quality TPL ass any day and this is why
VPLs are massively more popular than TPLs for the same task.

One that does not work as well as it looks and it depends on drag and drop is
a crappy VPL . Yes a crappy VPL will suck, not as much as a crappy TPL (see
C++ , Javascript etc) but it will suck none the less.

you can also read my quora answer here for more details why VPLs dominate so
easily and why they will replace TPLs in the not so distant future to a very
large extend

[https://www.quora.com/Why-did-graphical-programming-
language...](https://www.quora.com/Why-did-graphical-programming-languages-
never-really-%E2%80%9Ctake-off%E2%80%9D)

~~~
icebraining
If Blueprints have really become the default in Unreal, why are they so barely
talked about? Searching for "unreal blueprints" on Google returns less than
two full pages. Do you work in the industry?

~~~
kilon
Welcome to the failures of Google search engine. Google is great but not so
great when you try to make the search a bit smarter.

I am about to "work" in the industry I have a Blender plugin and Unreal editor
plugin in the works , none of the use a VPL by the way because simply what I
am trying to do is too technical for VPLs that target users and not coders.
But of course I will be offering VPL support because users love VPLs.

I never said Blueprints are the default in Unreal , C++ is still king. However
if you want proof , you can take a visit at the official Youtube channel of
Unreal by Epic and see for yourself the rise of Blueprints. Most tutorials
nowdays for making games with Unreal target Blueprints.

~~~
icebraining
Well, you said the rule of thumb was to use Blueprints unless you can't avoid
C++, that implies a default.

I do agree that Google's not evidence of anything, I just use it as a first
approximation when I have no better sources. That said, the marketing channel
of a company trying to push its tech doesn't really satisfy me either.

~~~
kilon
If that is what you mean by default then yes Blueprints are generally
preferred because they are accessible both by Artists and experienced
developers. C++ is generally preferred for performance reasons because
Blueprints being an interpreted language is around 10 times slower ( these are
estimates by Epic the creator of Unreal).

Of course how much Blueprints will be used will depend on the game. There are
games made entirely with Blueprints.

Also Epic recommends the use of Blueprints as first choice again because of
ease of use. They have invested a great deal to it after all. It even has a
debugger with break points , watching values and visualization of execution
flow.

------
tapirl
IfLoop is a visual programming language which is like text programming. It
gets both the benefits of the two styles. It is very good for new programmers
to learn programming. [http://www.tapirgames.com/blog/ifloop-web-
demo](http://www.tapirgames.com/blog/ifloop-web-demo)

------
unabst
Imagine trying to do math without numbers. That's why visual mathematics
sucks. Numbers are needed to count. We do it with our fingers when we're
little, and we're limited to 10. Then we take off our socks to get to 20, but
that's it.

Imagine trying to reason without words. That's why visual programming sucks.
Words are the smallest units of abstraction that we can reason with. So when a
visual programming language provides us with glyphs, we are already limited in
our vocabulary and in what we can reason with. It becomes excruciating.

What we need is not a visual programming language, but more tools to visualize
the programs that we have. Ultimately, all visuals need to fall back to
literal code a parser can reason with, so there is no escaping code. In fact,
there are already layers going down from the higher level languages that we
use now. A practical graphical language would be one built on a higher level
that adds a layer to the stack, and one which we can use or skip based on our
problem at hand.

Also it is because graphics too easily limit abstractions that most graphical
languages are best being domain specific. A WYSIWYG editor is for the web, the
form designer in Delphi was for application layouts, and Scratch is for games.

------
robertlagrant
My company sells a product that just does integration between things, and the
main way to program it is a visual language that does impedance-matching
between XML data structures, loops, conditionals, etc. For that it works
really well, and is superfast. But I can't imagine using it for general-
purpose programming.

------
tiago_simoes
Here's an article summarizing the major problems (real and perceived) of
visual languages [https://hackernoon.com/visual-programming-is-unbelievable-
he...](https://hackernoon.com/visual-programming-is-unbelievable-heres-why-we-
don-t-believe-in-it-ad52ba24c98)

------
whateveracct
Why is pictionary a fun game to play? Because drawing pictures to express
ideas is harder than using a language :)

------
nottorp
Funny enough, all examples of successful visual tools in this conversation are
domain specific (yes, even UI builders are domain specific). The ones
mentioned in the 'it's unusable' category are the ones trying to do
everything.

That should answer the OPs question better than any specific answer...

------
kevin_thibedeau
It is unproductive. You waste time managing a 2D representation for little
benefit. It's hard to do meaningful diffs and merging needed for revision
control.

You can program FPGAs in 2D with schematic entry. It is a huge time sink for
anything non-trivial which is why few bother with it these days.

~~~
DonaldFisk
> It's hard to do meaningful diffs and merging needed for revision control.

That's because existing revision control tools are specifically designed for
textual languages, therefore unsuited to graphical ones. There's no reason why
graphical equivalents can't be implemented.

------
nitrogen
Your example is still too closely tied to traditional textual methods of
programming: "query", "statement", "string interpolation", etc. are not likely
terms to be found in whatever visual programming paradigm eventually becomes
successful.

------
simonh
A picture might be worth a thousand words, but if I give you a thousand word
essay there's no way you'll find any number of pictures that fully express it.

Text is hugely expressive and can be precise and unambiguous in ways visual
information struggles with.

------
paulryanrogers
Klik & Play had a curious mix of questionnaire and spread sheet programming
when making games. I pushed it as far as a 14 year old could. I think the
density of information and need to control abstractions are where visual tools
break down.

------
dsego
You are describing asp.net forms in visual studio circa 10 years ago. It was
not a bad experience to use the UI tools and "code-behind", but then MVC and
Ajax came to the scene, and it fell behind I guess.

------
santaclaus
It has taken off in certain niches. When I was an undergrad all of the physics
labs were hella into LabView for developing instrumentation software. Most
shader development tools are essentially visual programming.

------
reaanb
Text doesn't interfere with a programmer's imagination or ability to visualize
the system. Visual programming suppresses imagination and imposes a very
limited and impoverished visualization.

~~~
jononor
On the other hand it can be really tricky to reconstruct an understanding of a
non-trivial system which someone else made from the textual code. With visual
diagrams overall architecture can be conveyed quickly and relatively
concisely.

------
nikofeyn
i think most people that have an opinion on visual programming have not
actually ever used a visual programming language in earnest.

i have worked in labview very seriously over the past 4-5 years. at this
point, i am essentially an expert in the language. i have done object-oriented
programming (OOP), functional programming, and also programmed using an actor
framework. all of that is in addition to obviously adopting the dataflow-first
paradigm. my projects have not been simple applications. they have been large
applications, with many different components and non-trivial user interfaces.

it's amazing how such a simple and small base language can be so powerful due
to the dataflow nature. my programs are almost always essentially bug free
when i am done. this is due to how labview works, which is rather advanced. as
i program labview, i work on VIs. these are small blocks of code that perform
a certain task. oftentimes, these are purely dataflow functions. in other
words, they take in information and pass information out without modifying
things via references. since every VI has dynamic type propogation and
compilation as you work on it, you get immediate feedback on wehther or not
your types match up and whether your VI runs. once your VI successfully
compiles (by the way, you never kick off the compile process as it's
automatic), you can run it. so i build up systems out of basic dataflow
processors, almost all of which i am able to run freely with inputs to see how
they interact. out of those that i can't, mainly due to needing a "mock
object" to test, it still makes it easy to reason about to due simply having
to understand how the data flows through your code. if something's not
available, it's pretty easy to trace it back to where it should have come
from. all of this also makes labview easy to debug. data is just flowing
through your program. just navigate to where you want to view your data and
place a probe on a wire to see what's happening at that point in your program.

all of this is quite advanced. this type of interactive writing of code,
running, and debugging doesn't really exist in other languages. then you have
the ability to easily create modern looking user interfaces (my interfaces are
almost untraceable back to labview based upon their look) and program desktop,
real-time OS, and FPGA applications all with the same language.

and i haven't even talked about how labview is concurrent by default. want two
while loops running concurrently? just draw two while loops on the screen, and
you're done. multithreading is so easy in labview that you don't even have to
think about it. it's inherent to the language, and labview takes advantage of
multiple cores by default.

many of these features are discussed ad nauseum in reference to other
languages: type propagation, REPLs, dataflow, concurrent/multithreaded
programming, etc. these are things people throw out in praise of a language,
and yet labview has all of them.

finally, i will mention that labview does struggle with some things, but it is
not due to the visual programming environment being inadequate in most cases.
most of the time it is because the language is manufactured by a company,
which has finite resources in what they can do to the language. there are
plenty of problems with labview, but they are all solvable. they just need
attention from national instruments and the research community at large.

it's just that visual programming is different and necessitates different
approaches. people somehow forget that it took them years to understand how to
program computers using text. it isn't that text is THE way to program
computers, but people certainly seem to think that. i am convinced a hybrid
approach is appropriate. i myself am slowly designing a language and
environment along these lines.

~~~
brenschluss
> i think most people that have an opinion on visual programming have not
> actually ever used a visual programming language in earnest.

Yes. I have used a dataflow language for 3d modeling - Grasshopper - for 5-6
years. I can't agree enough with you about the joy of interactive writing,
running, debugging, etc. Grasshopper also happens to have blocks/nodes where
Python/C# code can be inserted, which is the best of both worlds.

As someone who has never used labview - do you have any links to examples of
your work, or well-structured labview code?

------
jokoon
Look at this [https://scratch.mit.edu/](https://scratch.mit.edu/)

The idea is similar...

I'm really curious if one could compile this directly into some form of AST...

------
zmoreira
It doesn't. Try Outsystems:
[https://www.outsystems.com/learn/](https://www.outsystems.com/learn/)

------
TheLilHipster
[https://developers.google.com/appmaker/](https://developers.google.com/appmaker/)

------
gaius
What you're describing is Developer/2000 or more generally RAD which was all
the rage in the mid-90s.

------
adamb_
At the end of the day, programming is symbol manulation, and nothing beats
representing symbols like text.

~~~
DonaldFisk
No mainstream programming language even supports symbols as a data type. They
process numbers and strings of characters.

Symbol manipulation is done well only by Lisp and its variants.

~~~
lispm
Javascript (with ECMAScript 6) supports symbols as a datatype.

------
dukoid
1\. Try flowgrid.org

2\. File an issue describing why it sucks

3\. I'll fix it O:)

Ok, realistically, I guess I agree with the top comment

------
trentmb
What would the United States Code look like as some painting or interpretive
dance?

------
samblr
(may be) google app-maker (+ more AI) - something to watch out for.

------
sriku
Is there a VPL that's been developed without using any text?

------
andreapaiola
Have you ever try Drupal Views?

------
dalacv
please try Bubble.is

------
killin_dan
Honestly, I think most languages have shitty syntaxes (syntaxi?) and that the
issue is not about visual programming.

The other problem is that everybody who has a big idea for visual programming
has the same, actually shitty, idea.

Drag-n-drop blocks that represent logic.

UML is not a thing anymore because it's useless and wastes time.

Visual programming is great for describing high-level logic, but not low-level
semantics.

Try and describe your last trip to the grocery store with just emojis. Maybe
you might get creative and come up with a paper for your list, some fruits and
stuff like that, but how could you guarantee that the user on the other end of
your description gets the exact same idea? You can't.

With words, I can write my comment how I want, and I'm more or less guaranteed
that people will read it the way that I intended them to, because it wouldn't
make any sense any other way.

------
doggydogs94
I avoid Text as much as possible. I find that Text is good for command line
stuff. For building a good looking app, a visual tool mandatory. Of course, if
I want a quick and dirty clunking looking thing, Text is ok.

------
cocktailpeanuts
If you want an answer to your question, you yourself should know what you're
asking. I honestly don't know if you're asking a rhetorical question,
complaining about the reality, or asking for feedback on your idea. You are
talking about multiple things at once here:

1\. asking why visual programming sucks;

2\. Talking about your experience with Alan Kay;

3\. talking about your idea of an ideal visual programming method.

~~~
freehunter
Luckily we're on an Internet forum where people can take their time to read
the question and then have even more time to figure out how to respond, what
to respond to, and what to ignore.

It's entirely possible to have complex conversations here where more than a
single topic is being discussed at one time. This isn't Stack Exchange.

