A Domain-Specific Language is a programming language with a higher level of abstraction. Unlike low-level languages, which are applicable across different domains, domain-specific languages (DSLs) specialize in a particular subject area. You can't write all programs with a DSL like with a general (low-level) programming language. But for particular problems, a DSL could be a much more efficient tool than a general low-level language. To better understand the place and role of DSLs in the full spectrum of programming languages, let’s have a look at the categories of languages suggested by Ola Bini for multilingual systems. Bini identifies three layers of the application - the stable, the dynamic, and the domain layer, and considers them in the form of an inverted pyramid.
A stable layer is at the inverted top of the pyramid. Applications of this layer meet the highest requirements for performance, stability, and absence of errors. Writing programs in such languages are the most time-consuming and expensive. That is why the pyramid is inverted — after all, software of this level is doomed to remain in the minority. However, the cost of creating such software is fully justified if you need high performance or support for a significant code base scale. The first is achieved by eliminating the overhead of interpretation at the execution stage, and the second is removed by static typing, which provides a guaranteed external interface.
The dynamic layer contains programming languages designed to create software quickly. The life cycle of such software can be concise: from several hours to several months. Such software can also change frequently. This may be a demonstration of the prototype or a new version of the user interface for the sale promotion. Such software can be of high enough quality to fulfill its function, on the one hand, and be flexible enough so that the complexity of its creation is lower than in languages from a stable level, on the other hand. The optional type declaration in such languages leads to a significantly smaller amount of code, as well as the possibility of its reuse in cases where it is necessary to work with different types in the same way. This allows writing code quickly and efficiently. The absence of compilation also increases the development speed, as it eliminates unnecessary loss of assembly time and will enable us to upload the changed code to the deployment environment quickly. Besides, dynamic execution allows you to change the code “on the go.”
And finally, the top layer is the most unstable, with a low level of responsibility. The languages of this layer impose low requirements on the level of programmer’s knowledge and thereby provide a large army of developers. The main purpose of this layer is fast software delivery. This layer includes lightweight languages without type control for building front-end type software and the DSLs for creating application software. These are the languages of the leading edge, as close as possible to their consumers to such extent that even the knowledge of a non-programmer can be quite enough to make own website or even build their databases for personal accounting. The most significant volume of software is developed in this layer, and the widest part of the Bini pyramid corresponds to it.
1C Domain-Specific Language
1C is the programming language embedded in the 1C:Enterprise platform. 1C is an excellent example of implementing an external DSL. These are the main DSL features: first of all, it is a specialized language for solving the problems of its subject area:
- makes it possible to describe the solution in terms of the subject area at the design stage;
- the level of language abstraction allows subject area experts to understand algorithms;
- applications using such a language are concise and allow optimization and validation of work with the subject model at the platform level
A lot of applications in a wide variety of usage scenarios have already been written in 1C:Enterprise language, and these are not only accounting tasks. The language itself has built-in objects for working with files even at the byte level. All of this can be represented as written in a general language. Martin Fowler himself, who introduced the concept of DSL, noted in his work that sometimes it is challenging to attribute the capabilities of a language to DSL, and there is a fine line where the language goes beyond just one subject area and can already be considered as a general-purpose language. But let’s have a look at what the 1C:Enterprise platform language is.
The main limitation of 1C:Enterprise language is that algorithms can only be run in implemented platform events. The definition of the function called by the event is also predetermined by the platform and cannot be arbitrary. The platform also does not have the concept of a “library,” that is, code with its visibility scope. 1C:Enterprise language syntax and semantics are as simple as possible. All the main features of the language are implemented through the built-in platform objects. It is assumed that the main application functionality is implemented employing visual design in the Designer mode. You can change the typical platform behavior in 1C:Enterprise language in the event handler code.
1C:Enterprise language has many limitations that are not common for general-purpose languages. You cannot build an effective web server in this language or implement an interface that is not supported by the platform (try changing the highlight color of the current row of the table field). On the other hand, everything necessary for solving applied problems is maximally implemented in platform objects that are accessible from the language. The object semantics is defined at the platform level, and this ensures their support: data integrity, calculation of totals, access rights, presentation in the interface, etc.
According to the Bini pyramid, the layers of languages represent a fractal structure. In 1C ecosystem, this can be defined as a sequence of layers:
- subject area solution implementation
- implementation of basic functions in the subsystems library
- 1C:Enterprise language, query language, built-in objects
So we observe the effect of self-similarity of the Bini fractal pyramid at the level of the basic DSL language built into the 1C platform.
The conclusion about its possible development follows from the definition of 1C language as DSL. The language itself has not changed much, starting with version 1C7. All that changes in the platform are the composition of built-in objects and functions. And, which is most likely, this will continue: new objects will appear on the platform that will both provide new features and simplify existing solutions in 1C:Enterprise language. For example, objects have appeared that can be used to work with the storage history recently; however, a similar implementation, although less effective, has already been created earlier in 1C:Enterprise language as part of the basic standard library.
This article is an abstract of the longread Selecting programming languages depending on the task.
