Academically visible programming refers to programming using graphical symbols instead of coding text. The industry has not adopted visual programming for two reasons.
- Contrary to the common expectation that "a picture is more than a thousand words", most visual languages are more difficult to understand than coding text. The image is easier to understand than the text because it is more realistic. But the graphic symbols in a visual language are very abstract and the most difficult to understand from words by laymen.
On the other hand, the IDE has evolved to encode text a lot into rich graphical user interfaces. Therefore, Microsoft called their computer languages "Visual Languages": Visual Basic, Visual C #, etc.
One alternative "visible" versus "text" is "codeless programming." It does not use text encoding but is not strictly a visual language. Trying to visualize text coding. It usually relies on object programming and tries to visualize various aspects of object creation and linking objects. There are several systems that go in this direction. Some of them still use some text coding.
Some "unencrypted programming" is domain specific and is very successful because of strong software libraries in a specific field and because of their perception in a specific field, for example LabView for electronic device design. With regard to general-purpose programming, most “codeless” systems still suffer from a lack of rich software libraries.
One promising “blade-free” approach is the visualization of component programming. It visualizes current computer industry languages by visualizing event handling and visualizing object development. For standalone Windows applications, it depicts the creation of a .Net Framework object and event handling. The full .Net Framework libraries, from Microsoft or from any individual or corporate developer of the software, are the original building blocks of this programming approach. Programming results from such a programming approach are also .Net Framework objects and can be used directly by other computer languages that support .Net Framework.
Such an approach is possible because most modern computer languages rely on components. Programming entities are components. A component is defined with properties, methods, and events. The role of the text language is much less important than non-component procedural programming. In component-based programming, the text language works as a glue to bind the components together to form a new program, or as nails and nails to bind the blocks together.
It is also similar to using Lego blocks to form constructions. But Lego installations do not require glues, nails, and nails. It is because every Lego block is made with pins and sockets to be interwoven with other Lego blocks.
Modern software components are also made with screws and sockets to interlock with other components, because components can be crosslinked together by handling events. Handling events is one step ahead of object-oriented programming. If event handling can be performed with objects, no text language is required to stick the components together. This is the idea of codeless programming by visualizing component programming.