Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As the number of "visual" OS's such as Android, iOS and the promised Windows 8 are becoming more popular, it does not seem to me that we programmers have new ways to code using these new technologies, due to a possible lack in new visual programming languages paradigms.

I've seen several discussions about incompatibilities between the current coding development environment, and the new OS approaches from Windows 8, Android and other tablets OS's. I mean, today if we have a new tablet, it's almost a requirement for coding, to have, for instance, an external keyboard (due it seems to me it's very difficult to program using the touch screen), exactly because the coding assistance is not conceived to "write" thousands of lines of code.

So, how advanced should be the "new" visual programming languages paradigms? Which characteristics these new paradigms would be required?

share|improve this question

closed as not constructive by Yannis Jul 7 '12 at 3:53

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Get yourself access to the ACM Digital Library; the archives are littered with attempts at visual programming language. – Dave Newton Nov 13 '11 at 3:34
I'm not going to answer your question as I don't really have the knowledge. But, one thing that crossed my mind is Codea. Though it still require keyboard for easier development. – ariefbayu Nov 13 '11 at 6:45
I'm afraid there've been no progress at all since LabView. – SK-logic Nov 14 '11 at 8:54
Tablets: Strength = Consuming Content. Whereas Development = Producing Content. Don't mistake something being good for one thing as being a reason it must be used for another. Just like I don't try to genetically modify my steak so that a can-opener works as a better knife. – Dan McGrath Nov 14 '11 at 21:27
@Dan McGrath, tablets are not that hopeless in producing context. I write a lot on a tablet (plain text), and mind maps can be easily managed too. – SK-logic Nov 15 '11 at 9:32

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.

share|improve this answer
Would the use of a better interface (several large touch screens, 3D glasses and kinect, for example) make enough of a difference in order to make visual programming languages useful? – blueberryfields Apr 9 '12 at 2:39
@blueberryfields: Maybe, but programming will still be a multi-dimensional problem that you need to somehow map onto 2 or 2.5 dimensions, and I doubt such a graphical / visual programming environment would make things significantly easier. – tdammers Apr 9 '12 at 14:15
I think your objections regarding the different levels of code can be solved with the right paradigm. The searchability argument weighs more heavily I think. OTOH, it might be neat to be able to visualize data flow for debugging purposes. I think ultimately it's just that the right tool is missing to even convince the power users. I moved away from emacs eventually, too. – Christian Jul 5 '12 at 9:27
--An important reason may be that programmers are the ultimate power users.-- No they're not. People in a production environment are. If only programmers had to work with their own software for a week doing that same routine 500 times/day, then that routine would be a lot more userfriendly. – Pieter B Jul 5 '12 at 11:21
Power users as in "users who want to control their environment and go as fast as they can." – syrion Jul 5 '12 at 12:45

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.

share|improve this answer
I strongly disagree, language and texts are not expressive tools, graphics are expressive tools. Our brains are not wired to process thousands of lines of texts, they are ready to process shapes and colors in a very intuitive way. – Artemix Apr 30 at 21:06
So Tolstoy was barking up the wrong tree when he wrote War and Peace. Lack of available expression in text must be the reason no one has made a decent movie of it. – James Anderson May 4 at 9:10
Nice straw man there. – Artemix May 4 at 9:21
OK to be fair it boils down to Graphics for explanation, text for specification. – James Anderson May 4 at 10:17

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.

share|improve this answer
Ah -- sounds like another victim of OS/2s "Visual Age". – James Anderson Nov 14 '11 at 10:00
Well, it's not a very rigorous argument you are making yourself I have to say. From some assumed historical progression from visual to textual you conclude that visual programming is inferior. I'm not convinced. There clearly are reasons why visual programming failed and I'd be curious to here more speculation on this topic but there is a) no reason why the right visual representation should be any harder to proof and b) what portion of code is proved anyway? – Christian Jul 5 '12 at 16:23
I hear that C.S.Pierce had a diagramatic version of the Predicate Calculus, so I guess you can prove with diagrams if you try hard enough. For harder evidence about some particular diagramming tools I refer you to a reference in "Making Software" by Oram and Wilson P 20 "showing in experiment that a nested structure was comprehended more effectively using a textual representation [Green and Petrie 1992]" – mcdowella Jul 5 '12 at 19:56

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.

share|improve this answer
XSLT can do much more than just copy values over. – user1249 Nov 14 '11 at 7:20
Pay a visit to Unreal Engine 4, blueprints are a pleasure to work with. – Artemix Apr 30 at 21:08

"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.'

share|improve this answer
Any concrete reference for that Cubicon IDE ? It seems quite elusive on google. – Matthieu Dec 12 '11 at 16:19
I second @Matthieu's curiosity. – Christian Jul 5 '12 at 16:25
@Christian, here you go - everything there is to know about the Cube. Okay, for real, here is Cubicon - Trusted Infrastructure for the Ambient Cloud. – Cyclops Jul 7 '12 at 11:09
@Cyclops great, will have a look :) – Christian Jul 7 '12 at 11:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.