My opinion about block-based programming languages has changed progressively. At first I didn’t think they were serious and had little confidence in them, but as I have used them I have changed my mind. When I saw that children from 6 to 8 years old were able to create simple programs in a short time, I understood the didactic power they have. Later, I discovered some spectacular video games developed with Scratch, such as those made by https://scratch.mit.edu/users/griffpatch/. So I think that as languages to start in programming they surpass by far the text based languages. I can not imagine a child of 7 years (not a Mozart programming) programming and enjoy the simplest of text-based languages. Just overcoming the barrier imposed by language syntax already gives them a considerable advantage over text-based languages. In addition, the two-dimensional visual representation offered by lego blocks provides a powerful metaphor to the student that quickly fits the structure and flow of the program.
However, I believe that block-based programming languages have some shortcomings that prevent them from being used professionally. The first of these shortcomings is that subjecting them to version control is not immediate, much less practical. In professional applications, it is essential to use version control systems to maintain several development branches and allow collaborative work in which several programmers can work simultaneously even on the same part of the code. Merging code from other branches and resolving conflicts that occur in these mergers are everyday tasks in the professional environment . To do this, it is essential to have tools capable of showing and accurately locating the differences between two versions of the same code. This with plain text files is immediate, but with blocks… I don’t see it.
Another problem I see in block-based programming languages is what in an article I read some time ago (https://arxiv.org/pdf/1705.09413.pdf) they called “viscosity”. It’s that making small changes to the code when we use block languages is more expensive than its text counterpart. In fact, writing an algebraic expression in Scratch, if it is minimally complex, can be one job, and correcting it another.
Another problem for me (from my experience) is that I find it much more difficult to analyze the code of a “big” program in Scratch than that of a “big” one in, for example, Python. When you are analyzing the operation of a code it is vital to be able to make searches (especially of variables) and to make small changes to see how they affect. Sometimes it’s even convenient to have two or more files open simultaneously and in view to follow a reasoning. And I don’t see how to do that with block languages.
Finally, when we work with text languages we can structure the code in files, following architectures that are scalable and allow the program to grow and be modified without affecting the rest of the application. Here the batteries of unitary and integration tests play a relevant role. I also don’t see how to do this with the current block languages.
Possibly the tendency is to go the mixed way; platforms like pencilcode but that allow to work in local editors and to save the files in plain text format, so that we can use the fantastic help that the blocks offer about the syntax and the best vision that, sometimes, the blocks give to understand some structure or algorithm. It is also important that you can easily switch between editing blocks and text. And that the translation of text into blocks is as effective as that of blocks into text. In other words, to be able to use the best of each world.
Everything remains to be seen, but the truth is that, although the ultimate purpose of a programming language is to give instructions to a machine, the function they have as a means to express and communicate ideas is what makes them more or less useful, and in that sense block-based programming languages have many advantages. The (near) future will tell us.
Translated with www.DeepL.com/Translator (free version)