Defined Characteristics of a good DSL

All of we have a vague imagination about DSLs and here I am intend to talk about the DSLs with more details.

What is a Domain Spesific Language and its characteristics?

Unlike a general-purpose language like Java, a DSL is fairly limited in scope and capabilities; as the name suggests, DSLs are keenly focused on a certain type of a problem or domain, and on expressing a narrow set of solutions within the context of that limited scope.

Domain-specific languages (DSLs) are "targeted at a particular type of problem." Their syntax is focused on the intended domain or problem. You don't use them for general-purpose programming like you use Java, Groovy, or C++, because DSLs have a very limited scope and capability. A DSL is small, simple, expressive, and focused on a problem area or domain. DSLs have two important characteristics: they're context-driven and fluent.

Context is one of the characteristics of a DSL. As humans, we rely heavily on context when we communicate. We're efficient, and context provides for continuity in our conversations.Context gives meaning to the syntax. Context also influences interpretation. For example, you might interpret the words "use a fork" differently depending on context. Someone could be telling a child to use a fork at the dinner table. You could be being instructed to use the fork function to create a child process on a Unix-like system. Or perhaps someone is being coached on a chess move. When it comes to interpretation, context is very important.

Fluency is another characteristic of a DSL. It helps make code readable and flow naturally. It's not easy to design for fluency, but you should do it so it's easier on your users. Please take a quick look at the following implementation of loop in different languages:

// Java way
for(int i = 0; i < 10; i++)
{
println(i);
}
// Groovy ways
for(i in 0..9) { println i }
0.upto(9) { println it }
10.times { println it }

which one do you think is fluent? It is obvious that Groovy provides fluency for looping. Fluency indicates a very good information processing speed; i.e., very low average time between successively generated messages. While typically applied to language speakers, the term fluent can also apply to a language itself. The fluency of a language can be measured by how quickly and easily it allows users to process information.

When a DSL is considered as a good DSL?

Here simplicity and conciseness are discussed as two charactersitic to judge about goodness of a DSL.

1) Simplicity is critical to the success of a DSL. A person familiar with the language's domain must easily understand it. For example, if you're creating a DSL that actuaries will use to express business rules in the domain of insurance, you don't want them to spend a lot of time learning a difficult and complicated language. You want them to focus on expressing the details associated with insurance risks in a way that they can easily understand, discuss, evolve, and maintain. The DSL you create for them must be built on their vocabulary, the terms they use every day to communicate with their peers. You want them to use the syntax you provide, but it should seem to them that they're merely specifying some discrete rules. And they should be able to do so without getting the impression that they are really programming or even using some kind of a language.

Creating a good DSL is like cooking a nutritious meal; just like you want kids to eat vegetables without realizing and fussing over them, you want clients to use your DSL without worrying about its syntax.

2) Conciseness is another part of writing a good DSL, which means choosing syntax that is both terse and expressive. Terseness within reason makes your code easier to read and maintain. Expressiveness helps to promote communication, understanding, and speed. For instance, for someone who understands matrix multiplication, matrixA.multiply(matrixB); is less expressive and concise than matrixA * matrixB. The former involves calling functions and using parentheses, and includes an intimidating semicolon. The latter is already an expression that will be quite familiar.

Why use a DSL?

Ever you asked this question from yourself that why some people feel flexible working with command than GUI?

A GUI makes an average user productive, but can slow down an expert user or a user very fluent with your application and its domain. You don't want to make the novice productive and slow down an expert in the process. So the GUI is not always the most productive alternative.

The goal of DSLs is similar -- to provide a highly effective interface that allows users to interact with your application. The interface can be graphical or textual.

A DSL is highly expressive, simple, and concise at the same time. This can help the user of an application be more productive. A DSL is designed to be very intuitive and fluent for a domain expert to use (more about this in the second article in this series). It is designed with the convenience and productivity of users -- the domain experts, within the context of the domain -- in mind.

Future of DSL?

Martin Fowlerargues that applications will eventually come to use several small and limited DSLs instead of one big general-purpose language. Ola Biniargues that "three language layers will emerge in large applications": A small, stable layer on which the rest of the application is built; a substantial dynamic layer where most functionality lies; and a third domain layer, built using DSLs.

Further Reading

External and Internal DSLs

Please not that domain experts communication language derives the DSL and it is wrong to assume that the DSL forces the experts to follow our DSL to express their requirements.

We have a set of vocabs extracted from the target domain and our goal is to to shape them in a gramatical way to process it in a determined way ( I mean syntax and grammar). So, in developing DSL our major concern is syntax and its usefulness and expressiveness for experts.