Why isn't visual programming popular?

Visual programming is the idea that programmers (or even end-users) can program using a graphical notation. There are a number of reasons why this seems like a good idea:

• Programs are structural, not linear/sequential
• Textual syntax is difficult, and a barrier
  
• Graphical notation is richer - allowing new paradigms that would not work with text
• Direct manipulation - treating program components as physical things
• Programmers use graphical notations widely, both formally and informally

Of course visual programming hasn't actually taken off as expected. A lot of excuses have come up. Here are some of them:

• Yea, but we're stuck in a textual programming rut
  
• Almost all new programming languages fail; this is to be expected
  
• Workstations aren't graphical (not true any more)
  
• All VP systems are toy systems unsuitable for real world problems (true to an extent)
  
• Graphical notation is less compact (true, but there are solutions)
  
• Because early VP system sucked, people assume all VP systems suck
  
• Graphics is obviously better, we just haven't found the right approach yet.

Until recently, I would have had a great deal of sympathy with these views.

I've recently been working with use cases, which are a predominantly textual notation. The interesting thing is that there is also a graphical notation for use cases. The problem with the graphical notation is that it loses all precision, including extensions, preconditions, actors, goal level, stakeholders and interests, guarantees etc. In fact as a notation, UML use cases diagrams are very poor in comparison to text.

So we need to accept that fundamentally, some information is best presented as text.

Another problem is that the notation isn't as important as other aspects of software development. The text editor is just a convenient universal editor. It isn't the syntax which is hard with programming. It's annoying, sure, but it's not the crux of the problem. The crux of the problem is the design, the OO model, the functionality, memory allocation (if using C), the algorithms, the usability, the process, and the obsessive (male?) thinking. These are problems that aren't going to be changed by a graphical notation. In fact, using the text editor is probably the easiest part in the whole programming process!

What are the lessons from Visula?
In some ways, Visula is yet another VPL. A large part of it was written for fun - what would I come up with? In terms of scalability and practicality, it is orders of magnitude better than many other VPLs. If the question was: can VPLs be practical, usable and scalable, then the answer is a resounding YES! I didn't know this before. Hopefully that blows away some of the old prejudices, if anyone will listen.

Visula will not become a mainstream language though. It doesn't offer huge benefits over other scripting languages. I personally prefer the notation (which is really unique by the way), but that isn't enough on its own to persuade people to switch. Also the editor only runs on Windows, big mistake.

In hindsight, I should have based Visula on an existing scripting language, and created a graphical editor for the language. This would have been simpler to implement, and users would have no barrier to entry for the new notation. If they decide they don't like the editor, they can switch back to text. Creating a totally new language that nobody's going to use is fun, but pointless.

Recent trends
Before discussing new trends, let's review the current trends.

• Types: Strong -> Dynamic
• Style: Algorithms -> Glue
• Data: Bits and bytes -> Objects and patterns
• Expertise: High -> Low
• Environment: Textual -> IDE -> Tools
  
• UI: Text -> Desktop -> Web -> Web 2.0 -> Web apps.
• Data: Files -> Databases -> Mobility -> Sharing -> Community
  
• Paradigm: Procedural -> OO
• Memory management: Manual -> Automatic
• Data binding: Manual processing -> Drag and drop
• Databases: File -> Relational -> ORM
• Software: Small and buggy -> Big and bloated
• Quality: Low -> High
• Development process: Waterfall -> RUP -> Agile
• Interoperability: None -> Low -> Inherent
• Programmers: Generalist nerds -> Specialist communicators
• Usability: Terrible -> Low -> Better
• Platforms: Single platform -> Run anywhere. Desktop -> Web -> Mobile
• Libraries: Small and fragmented -> Monolithic and comprehensive
• Formats: Binary -> Text -> XML
• Automation: Low level languages -> Code generators -> High level language
• Reuse: None -> Libraries -> Platform

Future challenges
We still need to explore new notations - not because they are useful, but because they are interesting. It seems that all new work in HCI has to have proven immediate benefit backed up by experiments. This isn't blue-sky research, this is short-termism. Researchers should avoid making optimistic claims about the usefulness of their approach, but then they shouldn't need to.

There are a number of upcoming challenges to programming that software tools in general should address.

• Scale. Libraries are now tens of thousands of methods large. How does one manage such a large amount of data?
• Parallelism. We hear this all the time.
• End user programming. Includes teaching programming to kids. How does this translate into grown-up programming?
• Integrating programming with development process. Done in CASE tools. But there is a disjoint between CASE tools and programming languages.
• Tracking, collaboration.
• Web-based programming.
• Textual transformations.
• Reduce detail.
• Navigation.
• Searching.
• Make it tangible.
• Specify less.
• Manage detail.
• Guide the user. Often you stare at some code asking "what do I do next?"
• Create a top-down workflow where the programmer assists the tool, not the other way around.
• New paradigms. If I knew what they were, they wouldn't be new would they?
• Hide complexity.
• New abstractions, e.g. for parallelism.
  
• Reduce cognitive load. (A posh way of saying make it easier).
• Focus on the domain and the goal - not the technology.
• XSLT or other transformations between notations.
• Raising the level: Making programming more human and less nerdy.

What's clear is that transforming the textual notation alone isn't going to address these challenges. It might look pretty and nice, but it's not where the trouble with programming lies. I'm optimistic that graphics are better, but they are also a bit of a red herring.

As Fred Brookes said: There is no silver bullet. There is so much more research to do. Programming as we know it will change. I just wish I was clever enough to work out how.