Academically visual programming refers to programming using graphical notations rather than text coding. The industry has not embraced visual programming for two reasons.
Contrary to the common expectation that “a picture is worth a thousand words”, most visual languages are more difficult to understand than text encoding. An image is easier to understand than text because it is more concrete. But the graphic symbols in a visual language are very abstract and more difficult to understand than the words of the layman.
On the other hand, text encoding IDEs have evolved a lot into rich graphical user interfaces. Microsoft has called its computer languages ”visual languages” like this: Visual Basic, Visual C#, etc. Visual language researchers say that these are not visual languages because they are text encoding languages.
An alternative to “visual” vs. “text” is “programming without code”. It does not use text encoding but it is not strictly a visual language. Try to visualize the text encoding. It is generally based on object programming and tries to visualize various aspects of creating and linking objects. There are several systems that go in this direction. Some of them still use some text encoding.
Some of the “no code programming” is domain specific and is quite successful due to its powerful domain specific software libraries and due to its domain specific visualization, eg LabView for electronic device design. For generic purpose programming, most “no code” systems still lack rich software libraries.
A promising “no code” approach is to visualize component programming. Visualize existing computer languages in the industry by visualizing event handling and visualizing object development. For stand-alone Windows applications, it visualizes .Net Framework object creation and event handling. The entire .Net Framework libraries, from Microsoft or any software developer, individuals and companies, are native building blocks of this programming approach. The programming results of this programming approach are also native .Net Framework objects and can be used directly by other .Net Framework-compliant computer languages.
This approach is feasible because most modern computer languages are component-based. Programming entities are components. A component is defined by properties, methods, and events. The role of a text language is much less important than procedural programming without components. In component-based programming, a text language acts like glue to hold components together to form new software, or like nails and rivets to hold building blocks together.
It’s also like using Lego blocks to form buildings. But Lego constructions don’t need glue, nails or rivets. It’s because each Lego block is made with pins and sockets that interlock with other Lego blocks.
Modern software components are also made with pins and sockets to interface with other components, as components can interface with each other by handling events. Event handling is a step up from object-oriented programming. If this event handling can be done using objects, then a text language is not needed to bind the components together. That is the idea of programming without code through the visualization of component programming.