# Experimental Comparison of Editor Types for Domain-Specific Languages
## 6 Related Work  
The design and development of a domain-specific language is a well-researched topic [14]. Most of the research, however, has focused on the textual or graphical notations of DSLs. With the introduction of language workbenches with projectional editors, such as Intentional software [15] and JetBrains MPS, projectional editors have become a viable alternative. Projectional editors have been used in a wide range of languages, including a complex general-purpose language--extensions of the C language for embedded software development [16]. They have also been used as an alternative to form-based user interfaces. For example, JetBrains MPS was used to develop an interface for biological data analysis [17] or software requirements modeling [18]. The use of form-based editors as an alternative to a textual DSL has been demonstrated, for example, for a security policy specification language [19]. IIS*Case tool [20; 21] is using a combination of form-based, graphical, and textual languages for model-driven development of information systems. Some DSL development tools also support form-based editors, including Melanee [22] and EMF Forms [23]. Despite the collected experience, empirical evaluation and comparison of different types of editors are still limited. This is related to the overall lack of empirical evaluation in DSL research [24]. There are several studies comparing domain-specific to general-purpose languages. For example, [PERSON] et al. [25] conducted an experiment where they compared domain-specific and general-purpose languages for the task of graphical user interface definition. Participants of the experiments were given tests examining their ability to learn the used notation and understand the meaning of a program and modify it. The success rate of program comprehension was better in the case of DSL. Deeper analysis based on a cognitive dimensions framework showed that DSL was superior in all cognitive dimensions. In the follow-up study, [PERSON] et al. [26] used three different domains: feature modeling, graph description, and graphical user interfaces. They again found that the correctness of answers to test questions was significantly higher in the case of DSL compared to a general-purpose language. Participants also needed less time to complete the tests; thus, the efficiency of program comprehension was also significantly higher in the case of DSL. They, however, intentionally excluded the influence of editors on the results in both of the experiments. For this reason, the tests were taken on paper, so no software support tools or specific editors were used. All languages used in the experiment had textual notation. [PERSON] et al. [27] also compared DSL to a general-purpose language. It was a graphical DSL for the domain of High Energy Physics on the one hand, and C++ on the other hand. The effectiveness, efficiency, and confidence of the users were significantly better in the case of the DSL, but it was not clear how much the results were influenced by the editor of the language. Another similar study was conducted by [PERSON] and [PERSON] [28]. They used the domain of marine ecosystem simulation, and the participants were domain experts--ecologists. The compared languages were Sprat Ecosystem DSL and C++. They found significant improvement in correctness and time needed to complete the tasks using the DSL. As an editor, however, they used a simple, web-based text editing component with syntax highlighting for both languages. [PERSON]' et al. [10] investigated the influence of IDE features on the use of embedded DSLs. They compared a DSL based on the Ruby language, known for flexible syntax with a minimum of syntactic noise, with a DSL based on Java with more strict syntax. The Java-based language, however, used several IDE features to improve the editing experience, including generating the boilerplate code, hiding fragments of the code with syntactic noise and preventing their editing, code completion, and custom error reporting. Both languages were tested on non-programmers.