Why did visual programming never take off and what future paradigms might change that? [closed]

There are a few visual programming tools available, but for all I know, they are all horrible.

UML, which is basically a declarative visual language, is excellent for expressing the big picture, but for fleshing out the details of an implementation, it quickly becomes overwhelming and confusing. There are a few programming environments where you can create code by combining basic building blocks into something that looks a lot like a circuit diagram, but just like UML (or even more so), such diagrams quickly become confusing. Visual Studio, NetBeans, eclipse, and probably a bunch of other IDEs include visual designers for things like web pages and dialogs, and they mostly work, but despite their often astonishing quality, it is still impractical to build an application entirely in designer mode - text mode ultimately gives more control.

An important reason may be that programmers are the ultimate power users. Graphical interfaces excel at shallow learning curves; their intuitive interfaces make it easy to start using them, but the hand-eye coordination required to use them, as well as the mandatory visual feedback loop (you can't click something unless you can see where it is), somewhat limit the maximum input speed vs. a completely keyboard-driven system: physical keys never move, the expected response to a keypress can be anticipated upon, so even if you type into a sluggish ssh terminal session, you can keep typing without immediate feedback.

Another reason is that the meaning contained in source code has many overlapping levels. In a typical OOP project, you have a class hierarchy, which is basically a tree structure, with interfaces implementing cross references through the hierarchy. You have the code flow; imagine a huge flowchart to get an idea about the complexity of that layer. Then there's data structures, also embedded into the code - trees, lists, key-value collections, circular lists, hashmaps, etc. etc. If you're using threading, you introduce yet another level of meaning. With textual source code, you can look at the same piece of code with a different mindset and look at individual levels, zoom in and out, just by looking at the code differently. With graphical programming tools, you would have to switch to a different view - I can't imagine a graphical representation that contains flow, class hierarchy, data structures and threading relations at the same time.

And then there's the huge battery of text-based tools that we use on our code to make our lives easier: text-based search-and-replace, diff, version control, static code analysis, copy-paste (which does have its uses, e.g. for refactoring), code generators, etc.; also, embedding code into an e-mail or copy-pasting a chunk of code into a bug tracker are trivial. Basically, by making all code files text files, we can use battle-hardened tools that have been perfectioned for decades on code written in current and future programming languages.

On a well-meant side note: Are you seriously using a tablet to write code? Really? I would hate that; I always assumed people used a powerful desktop to build the code, and a tablet connected to it to run it.

Think of movies. This is the most "visual" medium in the arts, with color, movement, 3d etc.etc.

Now think about how they are made. Everybody works from a script. There may be some drawings and set designs attached. But it starts with a script and the day to day shooting is dictated by the script.

Language and text are incredibly powerful and expressive tools, visual tools are good for explaining, illustrating and simplifying things but the lack precise control is awkward. Also you lose track of whats happening in a complex diagram much more quickly that you do with well organized text.

In the datawarehouse space its pretty common to use "Visual" development environments for ETL. While this makes the simple things simpler its a nightmare to implement anything complex. Things like impact analysis become fiendishly difficult, and, source code control is almost impossible -- You know something has changed but finding out what becomes a "spot the difference" puzzle.

Note to visual programmers - I told you so! In the early eighties I was told about attempts at visual programming and observed that the history of geometry was 2000 years of progress from not very rigorous or well-defined visual representations to precise textual argument, at which point it becomes possible to prove things properly. Note that UML and many other visual modelling languages are in fact only visual representations of underlying network or textual data, precisely so that some rigorous meaning can be defined.

I have been impressed by one non-standard notation - "Parnas Tables" but these are really any more visual than code.

I've have a little experience with graphical programming, and for the most part that experience has been bad. Most of these systems are simple flow-charting systems, which are fine if you work on very simple systems. I've also used a data transformation tools with a graphical editors (essentially XSLT without the syntax). Again, for very simple transforms it was ok, but for anything real it was unusable.

There are things to consider that are rarely taken into account in these systems.

• Most programs these days are concurrent, and rely on mechanisms in the language for co-ordinated state change. Most flowcharting tools have no mechanism for organizing concurrent computations. An exception are implementations BPMN. This is a graphical notation for BPML, which has a strong theoretical foundation in the process calculi. While BPML is intended to be a complete implementation of the pi-calculus, it's adoption is weak, however a watered-down version called BPEL is gaining popularity as part of the WS stack.
• Exception handling also tends to be weak in flowcharting systems - complex software needs good exception handling.

But beyond the lack of features, the graphical programming systems I used were just painful to work with. It's hard to fit more than a dozen elements on the screen at a time before it gets to be a mess. You are constantly moving from mouse-to-keyboard and back. Coding in a text editor with syntax highlighting and auto complete take a fraction of the time.

"I'm afraid there've been no progress at all since LabView."

Good observation along with the other posting here, but the potential for visual (graphical) programming paradigms have only scratched the surface over the last several decades. New computer science is overcoming many of the drawbacks while offering the potential to truly engage the powerful pattern matching capabilities of our minds in the development of software systems, especially in the emerging parallel programming domain space. This new science is called Cubicon. Here is a conceptual description of this technology:

Icon expressions form the Cubicon invention, whereas its meta-object representations form the Cubicon innovation, fusing form and function as one medium. The development of Cubicon was self-contained. It was based on the premise that traditional programming approaches are no longer producing sufficient advances. Cubicon takes each of the language constructs that comprises the vocabulary of syntax, semantics, and context - and substitutes a graphical representation for the traditional use of every one of them a new interpretation. In short, Cubicon is a completely new graphical language, a new way of looking at the programming world, a clearly defined graphical algebra. As a graphical innovation, Cubicon supports the construction of a program in terms of a framework, the fusion of objects with their surroundings, and the combination of several views of an object expressed as language elements in a cube. This conceptual approach led naturally to a selection of simple geometric forms organized as interacting perspectives. The value of this approach to programming lies not only in the presentation of the language elements, but also in the dynamism that emerges from their composition, one that is perfectly controlled.

The ‘art’ of software development can evolve more quickly into a true ‘science’ through the wide adoption of Cubicon. Its science could lead to the third “killer app” category beyond the management of ‘words’ and ‘equations’: empowering a wide segment of the population with the ability to personally develop and manage general systems. This theory characterizes any system by the interactions of its components and the nonlinearity of those interactions.

Expressing abstractions such as a cat, mammal, and animal taxonomy in programming language words does not convey a sense of context in general systems. A ‘picture can be worth a thousand words’ with intuitive graphical abstractions. Cubicon leverages a basic human capacity to effectively deal with spatial information in the expression of general systems as a sharable mental Cube Model. Cubicon is a multiple paradigm language, enabling a domain expert to express intricate program structure and behavior in a completely syntax-driven and semantically bound declarative environment that effectively abstracts away the underlying computational engine much like an electronic spreadsheet.

The Cube Model has seven principle perspectives expressed as multiple schemata:

Topic Map - Graph substrate for topics and their associations

Genealogy - Ontology schema of concepts and templates

Composition - Parts-of-a-whole schema between collections

Network - Links between objects that carry messages

Collaboration - Directory of all software components and their dependencies with other communities

Image - Graphical user interface

Behavior (cube center) - Process-flow, control-flow, and finite state machine (FSM)

The Cubicon IDE also includes additional perspectives that collectively are used to capture, map and execute human intent within an immersive environment. General systems can be simulated in high definition where any selected language element can be instantly viewed from multiple perspectives, always remaining agile for recombination as system requirements change over time.

Declarative programming has been applied through many graphical dataflow-based languages over the years. These languages present prepackaged 'what' behavior in higher-level abstraction icons that can be connected through ‘wires.’ The challenge of this approach is the need for a source organization to support an explosion of icon types to cover all possible use cases. Placing the burden on their developer community to customize the icon 'how' behaviors requires a novice to crack open an icon into a scripting language. Thus, this approach defeats the original purpose of the declarative approach to shield the domain expert from this far less constrained text expression. Getting to an equivalent declarative approach like a spreadsheet requires a different approach for use in programming of general systems.

Instead of abstracting the ‘how’ away, the extended applied research work in Cubicon’s development tackled the task of fully automating imperative programming. This is where a micromachine-based language was an effective solution. It enables a domain expert to express intricate logic in a highly automated environment. Cubicon pushes the declarative language style down through control-flow and into the finite state machine (FSM) level of abstraction. Real-time execution is performed under a synchronous reactive model of computation (MoC) that guarantees deterministic interactions with the ambient environment. Not rocket science, just an exhaustive meta-design performed by decomposing the abstractions that comprise general systems, essentially removing the mystery out of working with the low-level programming 'gears and springs.'