Visual programming is a type of programming language that lets humans describe processes using illustration. Whereas a typical text-based programming language makes the programmer think like a computer, a visual programming language lets the programmer describe the process in terms that make sense to humans.
Just how big the gap is between visual programming and traditional programming depends on the visual programming tool. At one extreme, the tool shields the programmer almost entirely from the gaping space between human thinking and computers shuffling bits around memory.
Here’s an example. To create a to-do list with a visual programming tool, the programmer draws out the flow of the app. The resulting flowchart describes screens, user interactions, and what happens to the data at each stage. The tool then turns that into software.
As developers, we know that text-based programming languages focus entirely on the implementation: it’s all about the precise steps the computer must take in order to create the experience we want to give the user. Sure, higher-level languages and modern frameworks give us convenient shortcuts. But, the developer’s job is to translate human needs into processes that fit the computer’s limited abilities.
Other visual coding tools follow the same processes and paradigms as text-based programming. Imagine drawing a class and its relationship with the objects you instantiate, rather than typing it all out into a text editor.
All of this sounds great! But, you might ask, where are all the visual programmers? Why are we still writing code by hand? Does it mean visual programming is a bad idea?
Before we answer these questions and dive into the state of visual programming today, we need to understand what visual programming really is: where it came from, how has it evolved, and why.
A Brief History of Visual Programming Software
Although history seems to show it, it’s not fair to say that visual programming in the 1990s was confined to game creation kits, multimedia tools, and databases. Rational Software (which was acquired by IBM in 2003) had been building a non-GUI Ada IDE since the mid-1980s. In addition, they also turned their hand to defining the software development process. Work on their Rational Unified Process and related efforts eventually led to the Unified Modelling Language that had the potential to document every last part of a system without ever writing a line of code. It looked like visual programming but without producing executable software.
UML provided a standardized and comprehensive language for describing object oriented systems. However, UML-fever struck some architects. The co-author of The Pragmatic Programmer, Andy Hunt, tells the story of a software project where an architect spent two years creating UML diagrams before even a line of code was written.
Just as agile was gaining momentum, UML seemed to enable all the worst aspects of the old ways of building software: too much planning and too little implementation. Executable UML was an attempt to add that missing piece—the executable software. Several implementations surfaced but without making too much of an impact on a world that was rapidly switching its focus to PHP, Ruby on Rails,and other dynamic scripting languages.
Interestingly, one form of executable UML that did stick around also came out of Rational Software. Rational Rose is a suite of tools for creating software using UML and generating executable code in a target language, such as C++ or Java.
Back to the Future: The State of Visual Programming Today
Based on what history shows us, you might be wondering: is visual programming dead? Visual programming enthusiasts will tell you that it’s far from dead. Ask them "what is visual programming?" and first, they'll name an obscure domain-specific tool. Then, they'll tell you that tool is proof that it's alive and kicking. Meanwhile, you'll be frantically searching for it on Google. As a result, you'll learn not just about the tool they’ve mentioned, but also the highly specialized world in which it exists.
Without doubt, visual programming has its role, whether that’s programming synthesizers or giving UML enthusiasts a sense of accomplishment. For general purpose software, though, the world is just too complex to model purely visually. When your “code” looks like a CPU circuit diagram, it’s perhaps time to rethink the suitability of visual programming to the task.
Similarly, visual programming software tends to be limited by the imagination of the creator in a way that doesn’t hamper general purpose textual programming languages.
And yet tools like Visual Basic, Delphi, and their descendants have shown us that building software visually can be enormously efficient; it’s just that there’s a pragmatic trade-off where, sometimes, hand-written code is the right solution.
Superstars vs. Teams: A New Life for Visual Programming Languages?
Those early days of programming were hard, that’s for sure. But one person could understand and be expert in everything that was necessary to create that software. If you’re old enough, think back to software titles of the 1980s. It was common for a single programmer to become a brand in their own right.
Today, software is largely built by teams of specialists. Whereas early developers did everything themselves, a modern software development team might have one person whose only job is to look after the CI tool. Developers spend entire careers focused on one framework or platform. iOS developers are iOS developers, not mobile developers. Once or twice a decade, perhaps, a web developer might switch their preferred framework. Very few people are manually writing assembly language professionally.
It’s not just that the scope of software has changed. To some extent, developers themselves have changed, too. Software engineer is just another career these days. In decades gone by, it was a passion held by a few people who had the dedication to learn an entirely new system so they could write the Atari ST port, for example, of their successful Amiga game. But that’s understandable: computing is no longer niche.
Today, we have a world where software development is made up of increasingly complex parts and where developers are ordinary people with extraordinary specializations. That complexity and specialization are badly suited to the pure visual programming of those early tools but it also makes it increasingly hard to build rounded software engineering teams.
Where pure visual programming environments have failed, there is a whole cache of similar tools that take the best of visual programming and combine it with text-based coding. Whereas visual programming was “no-code,” these new tools are low-code.
Tools such as OutSystems let developers create software visually by drawing interaction flows, UIs and the relationships between objects, but supplementing it with hand-written code where that’s the better thing to do.
This pragmatic mix of visual programming and text-based programming is well suited to the needs of modern software development. Low-code platforms reduce the complexity of software development and return us to a world where a single developer can create rich and complex systems, without having to learn all the underlying technologies.
Next Generation of Visual Programming: Delivering on the Promise
Visual programming held so much promise and the problems that it wanted to solve haven’t gone away. In fact, they’re more relevant than ever.
But real-world problems demand greater flexibility than visual programming could offer. Low-code takes that promise and applies it to reduce the complexity we find in modern software development. So, ask not "what is visual programming?" Instead, ask "what is low-code?". You can also schedule an online demo or even try OutSystems (it’s free).