Conventional programming languages are difficult to learn and use, requiring skills that many people do not have. For this reason, user interfaces from a wide range of programs have begun to come with facilities that complement and facilitate programming capabilities.
Visual programming is programming in which more than one size is used to convey information.
Examples of such additional dimensions are the use of multidimensional objects, the use of spatial relations, or the use of the time dimension to specify the “before-after” type semantic relationships. Each multidimensional or relationship is a token, as in traditional text programming languages each word is a token. A collection of one or more such tokens is visual expression. Examples of visual expressions used in visual programming include charts, sketches, icons, or demonstrations of actions performed with graphic objects. When the syntax of a programming language (semantically meaningful) includes visual expressions, the programming language is a visual programming language (LPV).
Although traditional text programming languages often incorporate two-dimensional syntax in a very limited sense – an x-dimension to convey legally linear characters in the language and a y-dimension that allows optional spacing of lines in the document – only one of these dimensions transmits semantically. , while the second dimension was limited to information related to the typing of spatial relations so that they could be expressed in a one-dimensional grammar. Thus, multidimensionality is the main difference between LPVs and strictly textual languages.
When visual expressions are used in a programming environment as a quick editing facility for generating code, it is called a visual programming environment (MVP). These visual programming environments for traditional text programming languages represent a transition between LPVs and known textual languages.
Unlike a few years ago, when strictly textual and command-line programming environments were the norm, today MVPs for traditional textual languages have taken control in the world of programmers.
Commercial MVPs for traditional languages are designed for professional programmers. These programmers use the textual languages they already know and are helped by graphical user interface techniques and the level of accessibility of information that visual methods can bring. MVPs for traditional languages represent a way to transfer the advances due to LPV research into practice by applying these new ideas to traditional languages already familiar to programmers.
In this way, the gradual migration from the textual programming techniques to the visual ones is allowed.
As the LPV domain began to mature, the interest in creating a standard and robust classification for everything that was discovered appeared.
1. Pure visual language
2. Hybrid systems (text and visual)
3. Examples of programming systems
4. Constraint-oriented systems
5. Forms-based systems
In fact, these categories are not mutually exclusive, as many languages can fit into more than one category.
As in conventional programming languages, visual languages use two methods for controlling flow in programs:
1. The imperative method: in this case, the visual program performs one or more flow control charts or data flow charts, which indicate how the control is performed during the program.
A particular advantage of this method is that it provides an effective visual representation of parallelism.
The disadvantage is that the programmer must be careful about how the sequencing of operations changes the state of the program, which is not a desired feature for the system, especially if it is intended for beginners.
2. The declarative method: it is an alternative to the imperative method and assumes that the programmer must predict which calculations are performed and not how those calculations are performed.
Explicit state modification is avoided by using single attribution: the programmer creates a new object by copying an existing one and specifying the desired differences and not by changing the state of the existing object.