Academically visual programming refers to programming that uses graphical notations instead of text encoding. The industry has not embraced visual programming for two reasons.
-
Contrary to the common expectation that “an image is over a thousand words,” most visual languages are more difficult to understand than text encoding. An image is easier to understand than a text because it is more concrete. But graphic symbols in a visual language are very abstract and more difficult to grasp than words for the layman.
-
Without a rich software library as industry languages do, such as Java, JavaScript, .Net Framework, etc., a visual language can only have academic value.
On the other hand, text encoding IDEs have evolved a lot into rich graphical user interfaces. Microsoft has called its computer languages ”visual languages”: Visual Basic, Visual C #, and so on. 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 attempts 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 quite successful due to its powerful domain-specific software libraries and due to its domain-specific display, eg LabView for electronic device design. For generic-purpose programming, most “no-code” systems still suffer from a lack of rich software libraries.
A promising “no-code” approach is to visualize component programming. Visualize existing industry computer languages by visualizing event handling and visualizing object development. For standalone Windows applications, view .Net Framework object creation and event handling. Complete .Net Framework libraries, from Microsoft or from any software developer or person, are native building blocks of such a programming approach. The programming results of this programming approach are also native .Net Framework objects and can be used directly by other computer languages that support the .Net Framework.
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 as glue to join components to form new software, or as nails and rivets to join building blocks.
It is also like using Lego blocks to form buildings. But Lego constructions do not need glue, nails or rivets. It is because each Lego block is made with pins and sockets to interlock with other Lego blocks.
Modern software components are also manufactured with pins and sockets to interlock with other components, because components can be interconnected through event handling. Event handling is a step up from object-oriented programming. If this event handling can be done using objects, then you don’t need a text language to put the components together. That’s the idea of codeless programming by visualizing component programming.
Because “objects” are easier to understand than text languages, programming using visual object creation and visual event handling is easier to understand than text computer languages. If your visualization is done for industry-heavy component-based languages such as the Microsoft .Net Framework library, PHP, JavaScript, etc., this approach will take advantage of the vast and growing software libraries available. Therefore, this programming approach is easy to use and powerful in handling business requirements. There are some sample projects that use 3D libraries, some sample projects that use classes with generic types, and web applications that use PHP for web server processing.
