====== Qualities of a 'good' domain specific language ======

By Arslan Akhmetyanov (email: arakhmetyanov_1@edu.hse.ru)

===== Introduction =====

To start discussing the qualities of a "good" domain-specific language (DSL), it is important to first define what it is. According to Martin Fowler, a DSL is ‘a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem’ [1]. DSLs might be designed as a specific part of a more general language, e.g. as a library, or, in contrast, they can be a very distinct entity with their own syntax and commands. However, their purposes remain the same - provide a means of communication that represents the key features of a particular sphere and might be used as a common language for both developers and experts.

As a result, there are certain requirements for a DSL that help to provide advantages over general purpose languages (GPL). In the following essay we will explore the main qualities of a proper DSL and explain why we have found them important.

===== Existing criteria overview =====
As was mentioned before, any DSL has to unify experts, working in the same field. It means it has to cover the domain fully, and at the same time the language has to be clear enough for all the stakeholders. Nevertheless, this qualities are not enough to make the language 'good', so we will have a look on existing criteria. 

The topic of how to define a ‘good’ DSL has been discussed since the early 70s. One of the first important attempts made by Hoare, who suggested certain
 characteristics in ‘Hints on programming-language design’ [2]. These characteristics included simplicity, security, fast translation, efficient object code, and readability. These ideas were further developed in N.Wirth 'On the design of programming languages' [3], but it also has become outdated. It 70's there were serious performance issues, and as a result these works suggest several points to handle the situation. Nowadays, due to the growth in computing powers, they are not so urgent. However, the suggested concepts were important for the further development of the topic.


A more modern view is represented by Richard F. Paige, Jonathan S. Ostroff, and Phillip J. Brooke in an article called ‘Principles for Modeling Language Design’. This group of authors suggest simplicity, uniqueness, consistency, seamlessness, reversibility, scalability, supportability, reliability, and space economy [4]. These requirements are more abstract than those presented by the Hoare and are less dependent on the hardware. As a result, they better target experts because some stakeholders may not require technical nuances. As a result, such criteria can be generalized towards non-technical experts, and the qualities definition turned into more applicable and less verbose.


However, some of the experts admit that these requirements are not comprehensive as they lack implementation details. They suggest using the criteria as a set of guidelines for further discussion and actually provide just more practical advice [5].


In this work we would take a similar approach and will comment on the list, suggested in [4].

**1. Simplicity**

A good DSL should focus on the essential concepts of the problem domain. Unnecessary concepts make the language more verbose and increase the entry threshold, which excessively restricts the scope of application.

**2. Uniqueness**

Summary: There are no redundant or overlapping features.

Uniqueness (the same with an orthogonality) is a principle that ‘provides one good way to express every concept of interest, and it avoids providing more than one’. Having only one way to express the idea theoretically decreases the possibility of ambiguity.

**3. Consistency**

Authors insist that all the main features of a DSL should fit its purpose. Otherwise it becomes harder to support and fit other criteria.

**4. Seamlessness**

This quality significantly simplifies the implementation of the features which means a faster development.

**5. Reversibility**

As a transformation of the models into the realization is possible, a reverse operation has to be required. Avoiding fitting the criteria actually means that different stakeholders use different languages which might lead to inefficient communication.

**6. Scalability**

DSL should depend only on the sphere of application rather than on the size of a project. Otherwise it cannot be used as a unified language of the sphere which seriously limits its applicability.

**7. Supportability**

As a DSL is just an instrument for experts, it should be supportable. This means that the designed models can be handled in an appropriate way, otherwise they cound nit fit the purpose to the fullest.

**8. Reliability**

DSL should not encourage using antipatterns or reproduce common mistakes. As a result, it would be helpful for designing a proper system.

**9. Space economy**

DSL should not be verbose. Requiring a lot of space to represent models, firstly, makes using language less convenient, and, secondly, complicates the process of design and support.


===== Conclusion =====

After studying the sources mentioned in the essay, I generally agree with the view presented in the ‘Principles for Modeling Language Design’. All of the listed features are important for designing a proper DSL, however, we believe that one of them seems to be more of recommendations rather than requirements. This criteria is space economy. On the one hand, it actually helps avoid creating too big models which cannot be handled by humans. On the other hand, in the article creators’ view it is more about physical parameters of models in the language, and this seems more like a technical limitation that theoretically can be overcome.

One more point we would like to add is that the list lacks criteria for language extension and development. Surely, all the improvements should fit the listed qualities, but nothing is said about the extendability. We are not ready to provide a ready solution to the problem, whether we cannot be sure that that is a problem - but we suggest discussion on that.

All things considered, it is obvious that the problem has not lost its actuality. The suggested solutions have already passed a long evolution, and it definitely will continue. There are several reasons for that - starting from the lack of some desirable features (details on implementation, for instance) up to improvements due to the technical progress. The topic definitely requires further study, and we suppose that it will happen.


===== References =====
[1] “DSL Guide,” martinfowler.com, https://martinfowler.com/dsl.html#:~:text=A%20Domain%2DSpecific%20Language%20(DSL,any%20kind%20of%20software%20problem. (accessed Oct. 23, 2023). 

[2] Welcome | computer science, https://www.cs.yale.edu/flint/cs428/doc/HintsPL.pdf (accessed Oct. 22, 2023). 

[3] Electrical Engineering and computer science, https://web.eecs.umich.edu/~bchandra/courses/papers/Wirth_Design.pdf (accessed Oct. 22, 2023). 

[4] CITESEERX, https://citeseerx.ist.psu.edu/document?repid=rep1%20&type=pdf%20&doi=1f2e6f21b5f550ca96a5340aba6d976eff1b0726 (accessed Oct. 22, 2023). 

[5] Design guidelines for domain Specific languages - arxiv.org, https://arxiv.org/pdf/1409.2378 (accessed Oct. 22, 2023).