DSL

A domain-specific language (DSL) is a computer language that specializes to a particular application domain. This is in contrast to a general-purpose language (GPL). Further, this is broadly applicable across domains and lacks specialized features for a particular domain. There is a wide variety of DSLs, ranging from widely used languages for common domains, such as HTML for web pages, down to languages useful to only one or a few pieces of software. These include such an Emacs Lisp for GNU Emacs and XEmacs. DSLs can be further subdivided by the kind of language, and include domain-specific markup languages.

The line between general-purpose languages and domain-specific languages is not always sharp, as a language may have specialized features for a particular domain but be applicable more broadly, or conversely may in principle be capable of broad application but in practice used primarily for a specific domain.

A domain-specific language solves problems in a particular domain. However, it doesn’t intend to be able to solve problems outside it (although that may be technically possible). In contrast, general-purpose languages create to solve problems in many domains. The domain can also be a business area. Some examples of business areas include:

• Firstly, domain-specific language for life insurance policies developed internally in large insurance enterprise
• Secondly, domain-specific language for combat simulation
• Subsequently, domain-specific language for salary calculation
• Lastly, domain-specific language for billing

Further blurring this line, many domain-specific languages expose APIs. Further, this is easily accessible from other programming languages without breaking the flow of execution or calling a separate process, and can thus operate as programming libraries.

Programming Tools: DSL

Some domain-specific languages expand over time to include full-featured programming tools, which further complicates the question of whether a language is domain-specific or not.

To summarize, an analogy might be useful: a Very Little Language is like a knife, which uses thousands of different ways, from cutting food to cutting down trees. A domain-specific language is like an electric drill: it is a powerful tool with a wide variety of uses, but a specific context, namely, putting holes in things. A General-Purpose Language is a complete workbench. Further a variety of tools intends on performing a variety of tasks. Domain-specific languages are useful to programmers who, looking at their current workbench, realize they need a better drill and find that a particular domain-specific language provides exactly that.

Usage Patterns

There are several usage patterns for domain-specific languages:

• First of all, processing with standalone tools, invoked via direct user operation, often on the command line or from a Makefile (e.g., grep for regular expression matching, sed, lex, yacc, the GraphViz tool set, etc.)
• Secondly, domain-specific languages which  implementes using programming language macro systems, and which easily  converts or expands into a host general purpose language at compile-time or read-time
• Subsequently, embedded (or internal) domain-specific languages, implemented as libraries which exploit the syntax of their host general purpose language or a subset thereof, while adding domain-specific language elements (data types, routines, methods, macros etc.). (e.g. Embedded SQL, LINQ)
• In addition, domain-specific languages which are called (at runtime) from programs written in general purpose languages like C or Perl.
• Lastly, domain-specific languages which are embedded into user applications (e.g., macro languages within spreadsheets) and which are (1) used to execute code that is written by users of the application, (2) dynamically generated by the application, or (3) both.

Many domain-specific languages useful in more than one way. DSL code embedded in a host language may have special syntax support, such as regexes in sed, AWK, Perl or JavaScript, or may be passed as strings.

Design Goals

Adopting a domain-specific language approach to software engineering involves both risks and opportunities. The well-designed domain-specific language manages to find the proper balance between these.

Domain-specific languages have important design goals that contrast with those of general-purpose languages:

• First of all, domain-specific languages are less comprehensive.
• Secondly, domain-specific languages are much more expressive in their domain.
• Lastly, domain-specific languages should exhibit minimum redundancy according to the following subjective definition.

Redundancy is the average number of textual insertions, deletions, or replacements necessary to correctly implement a single stand-alone change in requirements. For a language, this is averaged over programs in the problem domain. This measure is useful because, the smaller it is, the less likely that bugs can be introduced by incompletely implementing changes.

Idioms

In programming, idioms are methods imposed by programmers to handle common development tasks, e.g.:

• First thing first, ensure data saves before the window closes.
• Secondly, before conducting expensive tests, perform cheap tests that can rule out need for expensive tests.
• Subsequently, edit code whenever command-line parameters change because they affect program behavior.

General-purpose programming languages rarely support such idioms, but domain-specific languages can describe them, e.g.:

• First of all, a script can automatically save data.
• Secondly, a smart test harness can learn what good tests are.
• Subsequently, a domain-specific language can parameterize command line input.

Advantages and disadvantages

 advantages

• Firstly, Domain-specific languages allow solutions in the idiom and at the level of abstraction of the problem domain. The idea is domain experts themselves may understand, validate, modify, and often even develop domain-specific language programs. However, this is seldom the case.
• Subsequently, Domain-specific languages allow validation at the domain level.
• Lastly, Domain-specific languages can help to shift the development of business information systems from traditional software developers to the typically larger group of domain-experts who (despite having less technical expertise) have deeper knowledge of the domain.

 disadvantages

• Firstly, the cost of learning a new language vs. its limited applicability
• Secondly, the cost of designing, implementing and maintaining a domain-specific language as well as the tools required to develop with it (IDE)
• Thirdly, finding, setting, and maintaining proper scope.
• Subsequently, the difficulty of balancing trade-offs between domain-specificity and general-purpose programming language constructs.
• Furthermore, the potential loss of processor efficiency compared with hand-coded software.
• Moreover, the proliferation of similar non-standard domain-specific languages, for example, a DSL used within one insurance company versus a DSL used within another insurance company.
• In addition, Non-technical domain experts can find it hard to write or modify DSL programs by themselves.
• After this, Increased difficulty of integrating the DSL with other components of the IT system (as compared to integrating with a general-purpose language).
• Further, Low supply of experts in a particular DSL tends to raise labor costs.
• Lastly, Harder to find code examples.

Make your resume stand out and become a Certified Capybara Testing Professional. Try free practice tests here!

A great career is just a certification away. So, practice and validate your skills to become Certified Capybara Testing Professional