Academically visual programming refers to programming using graphic notations instead of text coding. The industry has not adopted visual programming because of two reasons.
- On contrary to the common expectation that “one picture is more than a thousand words” most visual languages are harder to understand than text coding. A picture is easier to understand than text because it is more concrete. But graphic symbols in a visual language are highly abstractive and harder to grasp than words by laymen.
On the other hand, text coding IDE’s have much evolved into rich graphic user interfaces. Microsoft has thus called their computer languages “visual languages”: Visual Basic, Visual C#, etc. Visual language researchers are saying that these are not visual languages because they are text coding languages.
One alternative to “visual” vs. “text” is “codeless programming”. It does not use text coding but it is not strictly a visual language. It tries to visualize text coding. Usually, it is based on object-programming and tries to visualize various aspects of object creation and object linking. There are several systems going in this direction. Some of them still use some text coding.
Some of “codeless programming” are domain-specific and are quite successful because of their powerful software libraries in specific domains and because of their specific visualization in specific domains, for example, LabView for electronic device design. For generic purpose programming, most of “codeless” systems still suffer from lacking rich software libraries.
One promising “codeless” approach is to visualize component programming. It visualizes existing industry computer languages by visualizing event handling and visualizing object development. For Windows standalone applications, it visualizes .Net Framework object creation and event handling. The full .Net Framework libraries, from Microsoft or from any software developer individuals and companies, are native building blocks of such a programming approach. The programming results from such a programming approach are also native .Net Framework objects and can be directly used by other computer languages supporting the .Net Framework.
Such an approach is feasible because most modern computer languages are component-based. The 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 non-component programming. In component-based programming, a text language acts as a glue to link components together to form new software, or as nails and rivets to link building blocks together.
It is also like using Lego blocks to form constructions. But Lego constructions do not need glues, nails, and rivets. It is because each Lego block is made with pins and sockets to be interlocked to other Lego blocks.
Modern software components are also made with pins and sockets to be interlocked to other components because the components can be interlocked together by event handling. Event-handling is one step forward from object-oriented programming. If this event handling can be made using objects then a text language is not needed to glue components together. That is the idea of codeless programming via visualizing component programming.