Visual programming is why it's a bad idea.
The initial version of this publication received a great response to Reddit in the form of more than 300 comments. After that, I decided to add a small update to it in order to respond to some of the critical comments from the many arrivals.
A visual programming language is a language that allows a programmer to create programs by manipulating graphic elements rather than typing text commands. A well-known example is Scratch , an MIT visual programming language that is used to teach children. Its advantages are that it makes programming more accessible for beginners and non-programmers.
In the 1990s, there was a very popular movement to introduce visual programming into the corporate environment using so-called CASE tools, where corporate systems could be defined using UMLand generate [their code] without the need to involve trained software developers. This is due to the “round tripping” concept, where the system can be modeled visually, program code will be generated from the resulting models, and any code changes can be returned back to the model. Alas, such tools have not been able to fulfill their mission, and most of the experiments [on their implementation] are now largely abandoned.
Thus, visual programming has not gained popularity, except for some very limited areas. This situation is largely due to the following misconceptions about programming:
- Text programming languages confuse what is essentially a simple process.
- Abstraction and decoupling ( decoupling, reducing connectivity ) play a small peripheral role in programming.
- The tools that were designed to help programming are not important.
The first misconception insists that software development has a high threshold for entry, since text-based programming languages complicate the true nature of programming. Scratch's popularity among theoretical educators plays along with this misconception. The idea is that programming is actually quite simple, and if we could only present it in a clear graphical format, this would dramatically reduce the learning curve and mental effort required to create and read the program code.
I assume that this fallacy stems from the inability to actually read a typical program written in a standard text-based programming language, and to imagine how it is transformed into graphical elements from “cubes” and arrows. If you can still imagine this, it will immediately become obvious that one line of code is often associated with several “cubes”. Since even for the simplest program, the presence of hundreds or other lines of code is not unusual, its code will turn into hundreds or even thousands of graphic elements. Attempting to mentally disassemble such a complex picture will be much more difficult than just reading the equivalent text of the program.
The solution for most visual programming languages is to make “blocks” more complex, so that each visual element is equivalent to a large block of text code. The visual tools of the workflow are here a direct stumbling block.
The problem is, the code should still be defined somewhere. Therefore, the coding process [on large visual elements] turns into “programming the properties of dialogues”. The visual elements themselves represent only the highest level of program movement during execution, and most of the work is now done in standard text code hidden in visual dice. As a result, we took the worst of both worlds and received text programming that is not supported by modern tools.
Property dialogs are usually non-standard development environments and impose a specific choice of language, usually a script language of some type. The basic visual elements themselves can only be created by experienced programmers, and they can be thoroughly understood only by reading their basic code, so most of the perceived advantages of visual presentation are lost here too.
There is an impedance mismatch between the visual “code” and the text code (a set of conceptual and technical difficulties ), and the programmer has to navigate the interface between them, often spending more effort to improve the graphical programming tool itself than to solve the original problem [to write the program].
And now we come to the second misconception that abstraction and decoupling play a small role in programming. Visual programming is based on the assumption that most programs are simple procedural sequences, somewhat like a flowchart. As a rule, most novice programmers believe that this is how software works.
However, as soon as a program becomes more than a rather trivial example, its complexity will soon overwhelm the novice programmer. Beginners discover that it is very difficult to talk about a large procedural code base and often get bogged down in trying to create stable and efficient large-scale software. The main innovation in programming languages was the attempt to control complexity, usually through abstraction, encapsulation, and reduced connectivity. All systems of types and constructions of object-oriented and functional programming languages are really just an attempt to control the complexity of these languages.
Most professional programmers will constantly abstract and decouple the code. In essence, the difference between good and bad code basically lies in how well the programmer managed to do it. Visual programming tools very rarely have effective mechanisms for such things; as a result, the “visual” developer finds himself trapped in the available options, equivalent to the 1970s BASIC.
The last misconception is that visual programmers supposedly can do without all the programming support tools that have been developed for decades. Take a look at the long evolution of code editors and IDEs. For example, Visual Studio supports an efficient intellisense tool that allows you to pry through the thousands of APIs available in the base class library alone. Lack of good version control is another serious drawback to most visual programming tools.
Even if they save their layout in text format, “diffs” have no or almost no meaning. It is very difficult to make a 'blame' (find a commit and responsible for changing a particular string) in a large clump of XML or JSON. Things that have no meaning for the functional execution of a program, such as the position and size of graphic elements, all the while lead to changes in the metadata, which makes “diff” even more difficult to parse.
Text programming languages have learned to separate the structural blocks of code into separate source files, so changing one part of the system is easy to merge with changing another. Visual tools usually save the result on the “one chart per file” principle, which means that merges become problematic, and even harder if the semantic meaning of “diff” is difficult to analyze.
I was probably wrong when I took the Scratch screen shot and used it as the main example in my first paragraph. I am not a teacher, and I do not have my own opinion about the effectiveness of Scratch as a learning tool. Many people say that it is extremely useful in teaching programming, especially for children. Everything that helps people get into the wonderful and exciting world of programming should only be praised. I really didn’t intend to criticize Scratch specifically now, it’s just an example of a visual programming system that I thought most of my readers should have heard at least.
Another counter-example in Reddit was static structure tools, such as user interface designers, database schema designers, or class designers. I agree that they can be very helpful. Anything that helps visualize a data structure or a large-scale program structure is a bonus. But they are never enough. This is evidenced by the complete failure of tools from the 90s, such as Power Builder, which were based on graphical visualizations to create a development environment without the need to work with code.
About the author:
Notes, thoughts out loud, learning from everyone in sight, misunderstandings, mistakes, undiluted opinions. I'm Mike Hadlow, a preaching developer. I live near Brighton on the south coast of England.
The translation was made with the support of the company EDISON Software, which is professionally engaged in the development and testing of software .
Only registered users can participate in the survey. Sign in , please.