Domain-specific language

from Wikipedia, the free encyclopedia

A domain-specific language ( English domain-specific language , DSL for short ) or application-specific language is a formal language that is designed and implemented for the interaction between people and digitally working computers (“ computer language ”) for a specific problem area (the so-called domain ). When designing a DSL, efforts will be made to achieve a high degree of problem-specificity: the language should be able to represent all problems in the domain and not be able to represent anything that is outside the domain. This means that it can be operated by domain specialists without any special additional knowledge.

The opposite of a domain-specific language is a universally applicable programming language such as C and Java , or a universally applicable modeling language such as UML .

advantages

The advantages of a DSL over the use of a general programming or specification language include

  • less redundancy
  • declarative description of an issue
  • better readability
  • less technical code
  • domain-specific, static validation (external DSLs only)
  • easy to learn, due to the limited scope

Even end users can use DSLs, since they can be easily learned as a general-purpose programming languages. One speaks here of end user development .

disadvantage

  • For niche languages ​​or proprietary DSLs: Lack of language standards, certification options, free implementations, free or commercial libraries, literature, discussion forums, etc.
  • Effort for learning a new language with a relatively limited scope of the language; lack of opportunity or willingness of users to privately educate themselves in the language
  • Risk that the user has to carry out many development tasks (review, troubleshooting, runtime measurement, ...) in the language of the generated code due to missing or unsuitable utilities ("tools") for the DSL
  • Risk of a lock-in with internal ties to own program development or external ties to the provider of programs for a niche language
  • The risk that the opportunity to develop or use a new language will lead to insufficient efforts to find other sensible alternatives, such as the creation of comparably suitable abstractions in the languages ​​used up to now
  • The effort involved in determining the requirements for the new language, defining syntax and semantics, and implementing and maintaining the utilities (editors, compilers, debuggers, static code checkers, test environments, test coverage, metric tools) that are required for using the language
  • Difficulty in identifying the long-term required properties of the language: Does the language require a modular concept, the ability to define subroutines or data types, the representation of inheritance or interfaces or generic programming, or the ability to be integrated with code in other programming languages?
  • Risk of a creeping development of the language into a general programming language because the demands on the language increase and the language has to be expanded to include new concepts
  • Difficulty finding the appropriate level of abstraction
  • High demands on the competence of the language developer

Types of DSLs

A distinction is made between internal (embedded) DSLs and external DSLs.

Internal or embedded DSLs (internal DSL)

The internal DSLs (English internal DSL or also embedded domain specific language ) represent a subset of domain-specific languages , which use essential components of the language implementation of their host language. This reduces the implementation effort. An internal DSL is always a real subset of a more general language.

Prominent representatives of internal DSLs are:

  • Rake (the make for Ruby )
  • Xunit Frameworks
  • a domain-specific UML2 profile (stereotypes, stereotype properties and constraints)
  • a domain-specific XML schema (elements, restrictions)
  • Lisp-based DSLs

External DSLs (external DSL)

An external DSL is a language that has been redefined from the ground up. Both the concrete syntax and the semantics can be freely defined here. External DSLs are therefore considered to be more flexible and expressive. While the creation of external DSLs in the past involved a great deal of effort, today there are very good tools that make the development of external DSLs much easier, e. B. a so-called Language Workbench .

Prominent examples of external DSLs are:

Usage phases

DSL is a formal language and can therefore be supported by machines. While the definition, use and evaluation of the DSL are supported by existing tools (compiler, XML parser, XMI interpreter) for internal DSLs, new tools must be created for external DSL approaches.

Definition of language

First of all, the alphabet (domain-specific keywords) of the DSL and the domain-specific sentence formation rules must be defined.

Creation of sentences

In the next phase, domain experts create sentences that conform to the alphabet and the sentence formation rules and specify the technical conditions in their problem area.

Evaluation of sentences

After the technical experts have created their specifications, they need to be evaluated automatically and further processed automatically. A DSL can be transferred to another DSL by means of a domain transformation in order to further process the technical problem there. At some point, however, the area of ​​DSL will be abandoned and a domain-specific specification will be converted into a generic specification, which can then be converted into a problem solution using standard tools.

The domain-specific specification is transformed into another DSL or translated into a generic specification in the following ways:

Tools

  • AMMI - FAW GmbH
  • DEViL - University of Paderborn
  • DSL Tools for Visual Studio (Microsoft)
  • Eclipse Xtext (part of the Eclipse modeling framework project)
  • Eclipse GMF
  • EMFText
  • OOMEGA TMK (Textual Modeling Kit)
  • Intentional software
  • MetaEdit + - MetaCase
  • JetBrains Meta Programming System
  • MontiCore
  • Posity Design Studio
  • YML
  • Lisp

See also

literature

  • Martin Fowler: Domain-specific languages . Addison-Wesley, ISBN 978-0-321-71294-3 .
  • Georg Pietrek, Jens Trompeter (Ed.): Model-driven software development. MDA and MDSD in practice . Developer Press, ISBN 978-3-939084-11-2 .
  • Eric Steven Raymond : The Art of Unix Programming . Addison-Wesley Professional Computing Series. Addison-Wesley Professional, Boston 2003, ISBN 0-13-142901-9 , Chapter 8. Minilanguages ​​( catb.org [accessed July 13, 2015] discusses a number of domain-specific languages, some of which have existed under UNIX for decades ).
  • Thomas Stahl, Markus Völter, Sven Efftinge, Arno Haase: Model-driven software development. Techniques, engineering, management . 2nd Edition. Dpunkt Verlag, 2007, ISBN 978-3-89864-448-8 .
  • Markus Völter: DSL Engineering: Designing, Implementing and Using Domain-Specific Languages . CreateSpace Independent Publishing Platform, 2013, ISBN 978-1-4812-1858-0 .

Web links