You end up using Domain Specific Languages (DSLs) without explicitly realising. The strongest possible reason for this is that there is not much learning curve to adopting them. They provide total value by serving a specific set of tasks in a domain. They come as common as shell scripts or application specific scripts like Visual Basic for Applications (VBA) or as niche as GAL or Teapot.
Users who are experts in domain are well versed with the domain model, with its literature and behavior. The learning curve is too steep when they have to learn a generic programming language like C/C++ or Java to be able to write software for that domain. A bad side-effect is that lot of times the focus shifts from the programming for domain to the monstrous programming language itself. One way to solve this is to use one of the basic principles of usability - talk the user’s language. A programming language could
- already include the domain model
- include services for the domain users
- include domain’s natural vocabulary
- hide underlying technical details outside the domain
By including domain model, the DSL provides all the abstractions for entities, interactions and validations. Such a programming language can boost the productivity by simplifying programming for the users and is considered as a Domain Specific Langauge.
Probably now it is easier to realise why file management is so convenient in shell scripts as against in C. This does not mean that all programmig languages which include convenient file management features are DSLs. The shell scripts were built with the intention of programming the Unix shell and they provide all the services related to that. You will find it difficult to do web programming using shell scripts, because they are not meant for that.
Martin Fowler further classifies a DSL into internal and external DSLs depending on how it is implemented. He also comes up with the term of language oriented programming for the practice of programming using DSLs. Eric S. Raymond refers to them as minilanguages.
So why not develop a DSL for all projects! The biggest problem is that creating DSL is not a trivial task. An incomplete and inefficient DSL can be more harmful than using generic programming languages. Jamis Buck, who maintains Ruby On Rails, gives a rundown on creating DSLs. More often it involves using metaprogramming techniques of the source programming language. Not only does this require high technical expertise, it also demands deep understanding of the domain involved and its requirements.
But it will always pay if there is some research dedicated to analyze whether there are existing DSLs or creating DSLs for the domain you are trying to target. It can not only enhance productivity but also retain focus on the goal.
More reading:
November 20th, 2006 at 6:44 am
[...] Microsoft has added shell scripting capabilities to its upcoming server versions. Shell scripts are one of the most powerful tools for quick automation of tasks on operating systems. They are specialists, often considered as Domain Specific Languages, and are being extensively used on Unix-type platforms with variety of shells. While Windows did have the batch programs in the irritating command line interpreter with some intermedia scripting language, they were just a collection of command line arguments. Better late than never, Microsoft has introduced Windows PowerShell, which should help automating mundane tasks. It can be used on any current Windows family starting with Windows XP. A new syntax, a new language, but it will be useful to developers and administrators alike. [...]
August 16th, 2007 at 10:25 am
[...] what they mean the difference is on two levels - domain/application and language/interface. A DSL supports the domain model, which is known to the domain experts. It also tries to hide the [...]