Ask HN: Why does visual programming suck?

Beyond that, though, even when a sketch is a useful tool, I find I seldom use the computer to create it. A whiteboard, notebook, or back of an envelope all seem easier than working with typical graphical input mechanisms that are commonly available. Good touchscreens are a step in the right direction, but still far from perfect and far from universally available, especially on desktops. Aside from any innate problems with graphical programming in general, I think this input problem makes the approach generally unappealing at the moment. It's not an insurmountable issue, but until there are good input mechanisms that are as common as keyboards, I think you will just find that it is hard to reach the critical mass a new representation needs.

I know that input speed is not really a limiting factor in most programming, and maybe shouldn't be the deciding factor, but given how attached to their text editors programmers already are, and how disruptive and frustrating it can be to have to switch, I think it's clear that it is an issue.

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.

Accounting uses numbers, which in this context is text. If you replace a spreadsheet with a graph, your accountants will murder you.

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