Visual Programming Is Unbelievable… Here’s Why We Don’t Believe In It

Visual programming has been an unfulfilled prophecy for years. As so many other areas, like virtual reality, artificial intelligence, or speech recognition, when the hype was high, the underlying technology wasn’t there yet.

But that was not its only problem…

Several Misfires

For visual programming, the hype peaked in the early 90s with CASE tools. And, as with all trends ahead of their time, the repercussions of its failure were years of underinvestment, little innovation, and lingering skepticism.

UML (Unified Modeling Language), with its promise of bringing sanity to object-oriented programming, hasn’t helped either, although much of its faults were due to the underlying complexities related with inheritance.

And even more recent trends, like Business Process Modeling, probably did more harm than good in giving credibility to this area.

CASE tools, UML, and BPM all failed to deliver on their promises
CASE tools, UML, and BPM all failed to deliver on their promises

No Silver Bullet

In his seminal No Silver Bullet paper, Fred Brooks stated that there is no single development which, by itself, promises one order-of-magnitude improvement in productivity, because technology complexities would decrease, but requested features would not.

Like Moore’s law on hardware, the first part of that sentence proved to be prescient almost 30 years ago. What Brooks might have missed is that this would make room for too many directions in software development, often making us move in circles, instead of forward.

An example is the explosion of the number of languages, idioms and practices, sometimes with opposite approaches (e.g. strongly/weakly typed, client-server/server, all the different new JavaScript frameworks, etc…). Non-functional requirements, like scalability or security, and new expectations, like mobile and user experience, have only made things harder.


All this complexity opens space for an approach that would allow developers to focus more on delivering real value. Visual programming, with its higher level abstraction, could be the champion for this approach and become the productivity silver bullet we’ve been looking for.

So why hasn’t it yet?

Because visual languages have a fundamental set of problems:

Visual Languages Aren’t Extensible

This is probably the capital sin of visual languages. They allow you to do a limited set of things easily, but edge cases are far too difficult, or even impossible to achieve. Tools should give us more power, instead of limiting us.

Visual Languages Generate Slow Code

Every developer who has faced performance problems knows how hard they are to diagnose and overcome. Visual languages are leaky abstractions, often generating slow code which is impossible to optimize.

Visual Language Tools Can Be Terrible

We live and breathe in our IDEs (Integrated Development Environments). When they are poor, they can make our lives miserable! Visual languages and IDEs should be designed together: our love or hate for a language is a direct measure of our love or hate for its tools.

Visual Languages Lock You In

Any technology decision brings a level of lock in. The fear of being locked into a dead-end is justifiable, given that most visual languages generate unreadable lower level code, only target niche segments, are supported by suicidal startups, or haven’t left the research lab yet (where amazing recent work, like Bret Victor’s, is being done). Real success stories, of people using it in large projects, are still rare, and these communities are still growing.

You Are Neurologically Programmed to Reject It

The problems in the previous sections are serious and, as visual language architects, we know it’s our responsibility to continue our work to address them, removing these limitations.

But there are deeper reasons why you don’t trust visual languages:


The first is related to our love for complexity. Although we might say otherwise, we all do, according to the father of usability, Don Norman. Take musical instruments, for instance: musicians love them because they are hard to master. Think about legislation. Or even language: most poetry is hidden under complex sentences and words. We love the intellectual challenge of thinking difficult thoughts. Your mind is probably doing it right now, agreeing with these ideas, or checking if there is anything wrong or missing in them.

We need, however, to be careful with this, as we create deep moats against the rest of the world, and that brilliant xor swap algorithm I’ve coded today may be somebody else’s nightmare next year.

Like Steve Jobs said: “Simple can be harder than complex. But it’s worth it.”

The second reason is even more primitive: it’s fear of change. We take the time to acquire some expertise, and suddenly it seems our old weapons are no longer needed. But we’re seeing it wrong: our weapons are not to be able to do a malloc, or pointer arithmetic; they are to be able to divide a problem into smaller parts, to understand the process of iterating on its solution, to detect strange code smells, to discuss a diagram on a whiteboard, to refactor systems into better architectures.

Those are our real weapons, the ones we’ve been sharpening for years, weapons that, with higher level languages, become even more deadly to any problem that might cross our path. Fear not: a great developer will always be more valuable than any tool he works with.

And let’s face it: there’s also social acceptance. We were here first, we bought the debut albums, we’d never be caught listening to the sellouts that make it easy for everyone.

We’ve Been Here Before

Because of these instinctive reactions, anything that aims to democratize computing is met with skepticism. HyperCard, Delphi, Visual Basic, COBOL. We, the “real” developers, are too quick to point out their faults, and mock them with no mercy until they die, instead of helping them improve. Even JavaScript almost had that same fate during the DHTML days.


There is, however, an analogy that might better show us the future: The shift from text operating systems, like Unix and MS-DOS, to graphical user interfaces, like Mac or Windows, which suffered pushback from several computer experts at the time.

That evolution, which seems so inevitable today, brought us better graphic cards – which lead to better games, brought us the world wide web, brought us smartphones.

Can you imagine a world without these unbelievable things?

So, Are We Finally Ready For It?

Not sure: you may not, or you may feel we’re not – it’s fair either way. But try to understand your biases, and don’t be afraid to give visual languages a shot: there are several organizations like mine, in different domains, challenging the way software is traditionally delivered, and pushing forward the state of the art.

And even if, after trying them out, you still don’t see the bright future of visual programming, that’s fine: consider keeping an open mind and come back later, otherwise you might just end up in the wrong side of history.


About the author

Tiago Simões

A hacker, a tinkerer, and a thinker, who believes in making development faster for existing developers, while making it possible for everyone else.


Everyday I work on large and complex desktop applications for Mac and Windows, using the visual language Prograph. So I am a believer. In my case, there definitely is an order of magnitude increase in productivity, but there was also a required shift in viewpoint, from coding as writing instructions to coding as plumbing. It’s great to see more visual development tools coming along and I look forward to trying OutSystems development.

Tiago Simões

Hi Scott,

Curious to have your feedback. There will be always a learning curve of a couple of days, and some people that come from desktop applications development sometimes struggle with the paradigm shift to the web. The first videos of online training might seem a bit basic, but help consolidating some knowledge there, if needed.

Tiago Simões

John S.

Hi Tiago,

Are you aware of DRAKON, which came out of the USSR? http://en.wikipedia.org/wiki/DRAKON

What about NoFlo: http://noflojs.org/

I will look forward to seeing what outsystems comes up with in this area.


Tiago Simões

Hi John,

Yes, I was aware of both, they are very interesting. From a very superficial point of view, I would say they both show their age – in opposite directions :). I haven’t looked into them in a while, I’ll have a deeper look.

We already have a product in the enterprise applications domain (where shared data is the most important asset, and integration with existing systems is a must have). Would love to have your feedback.


Scott Jordan


I wouldn’t want to write a word-processor in it, but for quickly creating fast, truly parallel code with hooks to real-world devices (and yes, extensibility), there’s nothing better.

Tiago Simões

Yes, LabVIEW is a good example.

Delphi was kind of nice btw 🙂

The question which pops in my head is why would you write a blog post on a promises on visual programming rather than doing that via video? 😛

Also I know there are areas which ultimately feel better when done visually (like monitoring).

I guess it’s still about picking a set of proper metaphors and educating people. Or finding people which understand the suggested metaphors better. Both are tricky 🙂

Anyway, I’ll be glad to see this making business people doing more basic coding themselves 🙂

Tiago Simões

Yes Delphi was nice.

Regarding doing a video: that’s actually an excellent idea, I might create a presentation or a video for this. But if you look closely the article is not only text, it has formatting and images to make it easier to digest. In any case you are right, text will always play a major role in any programming language.

And I agree with you, there are areas where visual is definitely even more appropriate, user interfaces being an obvious candidate.

Thanks for your feedback.

I have a theory that GUIs could be used to educate people how to be more effective on the command line and better at coding. The rise of Windows and Mac OS may be the result of 1) people are initially more attracted to something “visual” and 2) lack of good code scaffolding code has required us to write a lot of boiler plate. Code scaffolding is getting super easy (see yeoman.io), and perhaps now all we need to do is build in some reminders of how to do each operation you do in a GUI could be more efficient from the command line. What if your Git GUI taught you the commands that it was running as it ran them? After hiking your mouse across the screen like a treasure hunt, are you really going to not just type out the command next time? This is a theory anyways, something I’m interested in testing. I think I’m going to write a GUI for pulling data from a sensor and sending it to an arbitrary database that shows you the commands being run underneath. Then I’ll collect usage metrics and see how effective it is at getting folks to use the command line (which will be conveniently always at the bottom of the screen). I’m inspired by the classes I’ve taught where some folks are doing basic file operations and it takes them 10x longer.

Tiago Simões

Hi Steinert,

That is a good idea. There is some software does that, e.g. autocad has (or at least had) a small command window on the bottom that you can use directly and that shows the equivalent commands that you do in the UI. Very useful for expert users and those who want to become.

Tiago Simões

Hi Tiago,

I fully understand what this article is about, but I wouldn’t say it’s caused by “Visual Programming”, but by “Highly Abstract Programming”.

Visual Programming, to me, is just another way of presenting code. Some like it, some don’t. For some uses it’s apt (discussing, explaining, discovering), for some uses not so much (profiling, debugging). And it can be exchanged easily: same information can be displayed as diagram or code, no problem about that at all.

Highly Abstract Programming, to me, is what we’ve been and are trying with CG, CASE, MDA, DSLs, you name it. All the issues you mention apply here, independently of text or diagram. BTW, my opinion is, there will be no alternative to this kind of programming in the nearer future (it might be named differently, then).

Kind regards,

Tiago Simões

Hi Andreas,

Yes you are right, most stuff applies to all high abstraction languages.

Regarding profiling and debugging, I think that was a problem a lot more present in old visual programming languages, but visual representation can actually help there (e.g. highlight traveled code paths, show charts of timings, etc…).

I’ve focused more on visual because our instinctive biases are even more present for visual languages.

Programming can never look that easy!

Thanks for your feedback,

I don’t get it – from what I see, the OutSystems platform is kinda like visual programming. Is it not?

Tiago Simoes

Hi Bruno,

Yes it is. That does not mean we don’t recognize there are problems with visual languages that need to be continually addressed. That’s what we do. If you read the article carefully you’ll see that we believe they are really the future.

Thanks for your comment,
Tiago Simões


I 100% agree that they only target a certain niche. I think that’s why PureData and Max/MSP IDE’s are actually great, they are made with a specific group of people in mind, you can build scripts in them if you are more advanced, but for the most part, it’s been designed for artists that know little to no code and are able to visualize the flow of a signal. Great article.

Tiago Simoes

Thanks for your comments. You might want to check out the OutSystems Platform wich targets (the very large) niche of enterprise applications. Would love to have your opinion.


Hi Tiago,

I found this article via hacker news and just finished it. Good stuff.

I think you may enjoy hearing about a project we’ve been working on at our hacker space. Idk if it will be of any relevance or help to what you’re doing… But it might. I’ll be at Sxsw next week. If you’re around we should meet up.

Keep up the good work.


Tiago Simoes

Thanks a lot for your comments. Unfortunelty I won’t be attending Sxsw. But you have my curiosity about your work.


I don’t see visual programming as a replacement for textual representations of code. It is just another perspective on programming and code. I love visual programming languages for prototyping applications. As part of my PhD I wrote an open source IDE that combines visual and textual programming (VRL-Studio). For most projects, I tend to mix both, visual and textual programming which dramatically increases my productivity.

Tiago Simões

I agree. It’s a bit like command line interfaces and GUIs, most modern GUIs are adopting powerful command lines, taking the best of both worlds.

j. landry

I agree with some of this assessment. I think the problem lies more in the justification to let non programmers have access. Id argue that leaving the brainiacs in charge who love to grind the processor and benchmark and all of these things have no use to someone who just wants a quick a dirty tool. Visual programming is not for low level and arguably never was.

Regarding speed, we live in an abundance of horse power and memory yet the average user is still treated like a second class citizen when it comes to tools and designing their own. Code speed isnt important anymore if the end result happens in less than a second. Id argue that maybe its time visual languages start moving toward self contained environments so as to keep the engineers away. The minority is the programmer dictating the pop culture’s ability to do their work undisturbed.

I think this in and of itself is why the divide between user and programmer are so wide and that most people dont even understand that a computer is more than a phone with a tv and radio built in…either the elite need to accept middleware and work with the upcoming wave of nonprogrammers who want to effectively morph their system using this vulgar amount of wasted processor power or they can continue to create esotheric single use languages and argue in a bubble until the chips rot.

Just my two cents as a novice who uses middleware which consistently makes unnecessary brick walls in the random scripting and diagramming structures…

In the end, I think something like smalltalk which now has enough horsepower to run can be a diving board into hybrid languages that are at once itself an ide and the finished program…a program that morphs with the user and leaves the keys to the back door underneathe the mat when the user feels theyre ready to really dig into it.

ie…a visual language is nothing if it doesnt go as deep as you want and ONLY when the user\programmer wants to go that deep.

ideas like lively kernal, while still slow since its forced to operate on a horrible paradigm, show a possible direction to take visual programming from joke to universal.

Dave Winberg

This is a very biased opinion that I think ignores decades of highly successful visual programming languages.

Where the author is making their mistake is assuming that because a language hit end of life that it was a failure. That’s a by product of progress not a inherit limitation of the visual paradigm.

The other mistake is not properly identifying the stakeholders. For many visual programming languages was a low barrier way for non-programmers to do some programming things.. In those cases the edge cases that were mentioned a moot point. The language wouldn’t have to hit those targets to provide value to most of the users.

The biggest problem with this argument really stems from the arrogance of developers versus the reality of most users (including power users). If you try to judge the usefulness of a limited language be it hypercard, Automator, flow based programming versus even a scripting language it’s going to fail.. They are literally different things that meet different needs..

Tiago Simões

Quite the opposite, if you read carefully you’ll see that I enumerate the historic problems that visual languages sometimes have shown, but what I focus more than anything is the skepticism technical people have towards them. Most probably I was not clear enough.

Leave Your Comment