Visual programming vs DSL

Recently, low-code and no-code platforms have been gaining popularity. They propose to use visual programming to develop applications. With this approach, developers, who are ordinary business users, instead of writing program code, create an application using the mouse in a graphical interface. Also, visual programming is used in some form, for example, in the 1C Configurator.

However, a question arises. What are the benefits of visual programming over Domain Specific Language? Of course it depends on the application. On the one hand, visual programming is practically not used in classical languages. At the same time, when developing a graphical interface, this approach certainly has many advantages. However, when creating interfaces, for example, using the popular React library, flat code is still used more.

Advantages and disadvantages

I see the following advantages in using DSL:

Version control system support. In visual programming, it is much less convenient to keep track of changes in the program logic and resolve conflicts in commits.
Ability to copy / paste, search and replace by text values, code generation.

In visual programming, the pluses include the following:

Lower entry threshold. Most users know how to click buttons, enter values into fields, and drag and drop objects on forms.
Better visibility when creating a user interface.

It should be noted that DSL and visual programming are not alternatives to each other. With the right approach, a visual designer can and should generate a DSL. XML is often used as such a language. However, the readability of XML leaves much to be desired.

Scope of application

One of the main disadvantages of visual programming is still too limited scope of its application. Yes, it is quite good for creating simple CRUD applications. However, when some complication of logic is required, then you still have to return to the program code. This creates a certain semantic gap when part of the logic is created visually, and part is created using classic code.

Using DSL, in turn, allows you to create fairly complex applications with much less effort. Writing code in a specialized language can seem like a daunting task for users. However, do not forget that the SQL language was created specifically for ordinary users, and is still used not only by programmers. And if the DSL is as high-level as SQL, uses ordinary words instead of special characters, then the entry threshold is significantly reduced (here example one of these languages).

Of course, a graphical interface is much better suited for managing “dynamic” systems than a text one. For example, most users still use the graphical shell of operating systems, and not the command console (although, in my opinion, the console is more convenient in places for managing servers). However, programs are more static systems. As a rule, changes in the operation of programs are carried out routinely, rather rarely, and may lead to other significant changes (for example, data migration). And in this case, the importance of checking the changes made is significantly increased, which is much easier to do with flat program code.

IDE

One of the distinguishing features of visual programming is that the developer immediately sees all the possibilities of the development environment. Thus, he has to turn to documentation much less frequently. On the other hand, it creates visual complexity, thereby “blurring attention”. It is more difficult for a developer to understand which settings he has changed and which are set by default. In flat files, all changes can be easily seen using the version control system.

In general, the use of DSL allows you to create significantly more powerful IDEs due to the fact that all modern IDEs have powerful mechanisms for developing plugins for custom languages. Therefore, it is easy to create a powerful IDE that is much more convenient to use than IDEs written from scratch for visual development. What are we actually donewhile receiving an IDE that is significantly superior in capabilities to the same 1C Configurator.

Conclusion

Developing a worthwhile solution is actually the hardest part of the software development process. The Low Code tools, while focusing specifically on visual programming, exaggerate by claiming that coding is the hardest part. In fact, no Low Code tool will save you the trouble of wasting time designing your custom software properly, or the consequences of building solutions around bad architecture.

A person who can design solutions more or less normally will be able to master DSL without any problems. At the same time, in complex development, flat code will be much more convenient for him for the same reason why in classical programming it is the language that is used instead of visual programming.

In the end, I would like to mention one more important plus of DSL. Most likely, in the near future, such languages will increase in popularity in relation to visual programming, as AI technologies develop. We tried to teach ChatGPT our brand new language, and the results were very interesting and promising. Quite possibly, some time later, DSL can be used to automatically generate programs based on natural language requirements. The chances of this are much greater than with classical programming languages.