Domain Specific Languages
Domain Specific Languages, abbreviated as DSL, are programming languages or specification languages that target a specific problem domain. They are not meant to provide features for solving all kinds of problems; you probably will not be able to implement all programs you can implement with, for instance, Java or C (which are known as General Purpose Languages). But if your problem's domain is covered by a particular DSL, you will be able to solve that problem easier and faster by using that DSL instead of a general purpose language.
Some examples of DSLs are SQL (for querying relational databases), Mathematica (for symbolic mathematics), HTML, and many others you have probably used in the past. A program or specification written in a DSL can then be interpreted or compiled into a general purpose language; in other cases, the specification can represent simply data that will be processed by other systems.
For a wider introduction to DSLs, you should refer to Fowler 2010, Ghosh 2010, and Voelter 2013.
So, why should you create a new language?
You may now wonder why you need to introduce a new DSL for describing specific data, for example, models or applications, instead of using XML, which allows you to describe data in a machine in human-readable form. There are so many tools now that, starting from an XML schema definition, allow you to read, write, or exchange data in XML without having to parse such data according to a specific syntax. There is basically only one syntax to learn (the XML tag syntax) and then all data can be represented with XML.
Of course, this is also a matter of taste, but many people (including the author himself) find that XML is surely machine-readable, but not so much human-readable. It is fine to exchange data in XML if the data in that format is produced by a program. But often, people (programmers and users) are requested to specify data in XML manually; for instance, for specifying an application's specific configuration.
If writing an XML file can be a pain, reading it back can be even worse. In fact, XML tends to be verbose, and it fills documents with too much additional syntax noise due to all the tags. The tags help a computer to process XML, but they surely distract people when they have to read and write XML files.
Consider a very simple example of an XML file describing people:
<people>
<person>
<name>James</name>
<surname>Smith</surname>
<age>50</age>
</person>
<person employed="true">
<name>John</name>
<surname>Anderson</surname>
<age>40</age>
</person>
</people>
It is not straightforward for a human to grasp the actual information about a person from such a specification: a human is distracted by all those tags. Also, writing such a specification may be a burden. An editor might help with some syntax highlighting and early user feedback concerning validation, but still there are too many additional details.
How about this version written in an ad-hoc DSL?:
person {
name=James
surname=Smith
age=50
}
person employed {
name=John
surname=Anderson
age=40
}
This contains less noise and the information is easier to grasp. We could even do better and have a more compact specification:
James Smith (50) John Anderson (40) employed
After all, since this DSL only lets users describe the name and age of people, why not design it to make the description both compact and easy to read?