A Domain Specific Language is a programming language with a higher level of abstraction optimized for a specific class of problems. A DSL uses the concepts and rules from the field or domain.
A Domain specific language is usually less complex than a general-purpose language, such as Java, C, or Ruby. Generally, DSLs are developed in close coordination with the experts in the field for which the DSL is being designed. In many cases, DSLs are intended to be used not by software people, but instead by non-programmers who are fluent in the domain the DSL addresses.
Using DSLs can reap a multitude of benefits. The most obvious benefit of using DSLs is that, once you've got a language and a transformation engine, your work in the particular aspect of software development covered by the DSL becomes much more efficient, simply because you don't have to do the grunt work manually. If you are generating source code from your DSL program (as opposed to interpreting it) you can use nice, domain-specific abstractions without paying any runtime overhead, because the generator, just like a compiler, can remove the abstractions and generate efficient code.
If you have a way of expressing domain concerns in a language that is closely aligned with the domain, your thinking becomes clearer because the code you write is not cluttered by implementation details. In other words, using DSLs allows you to separate the essential from incidental complexity.
DSLs, whose domain, abstractions and notations are closely aligned with how domain experts (i.e., non-programmers) express themselves, allow for very good integration between the techies and the domain people.
Using DSLs and an execution engine makes the application logic expressed in the DSL code independent of the target platform. Using DSLs can increase the quality of the created product: fewer bugs, better architectural conformance, increased maintainability. This is the result of the removal of (unnecessary) degrees of freedom, the avoidance of duplication in code and the automation of repetitive work.
There are two fundamentally different ways of how traditional code and DSL code can be integrated. The first one keeps DSL code and regular code in separate files. The DSL code is then transformed into programming language code by an automated code generator, or alternatively the program loads the domain-specific code and executes it. This first approach, with separated General Purpose Language (GPL) and DSL code is termed external DSLs. Think of SQL as an example of an external DSL.
An alternative approach mixes DSL code and general-purpose code in the same program file, leading to a much tighter integration between them. The DSL reuses the grammar and the parser of the GPL and exploits available extension options of the host language. The term internal DSLs is used to describe such scenarios.
It is worth to mention that some GPLs are more suitable for extension than others.
Both approaches can make sense, depending on the circumstances, and MPS supports both.
A DSL's structure and syntax was defined by writing code in the language into which the DSL code was to be embedded. Usually, IDEs did not know about the DSL and hence did not provide support (code completion, custom error checking, etc.). With MPS, however, you use the MPS framework with its specialized DSLs for language development to define language extensions. The IDE thus knows about them, so the system can provide full IDE support for the domain-specific embedded languages.
The term language-oriented programming was coined by Sergey Dmitriev, the CEO of JetBrains and "father" of MPS in his 2004 article, Language Oriented Programming: The Next Programming Paradigm. Other people have come up with related approaches, usually under different names; a primary example is Charles Simonyi and his Intentional Programming approach, and Martin Fowler has described the approach in his 2005 article Language Workbenches: The Killer-App for Domain Specific Languages?.
The core idea is that we don't just use one language when developing software, but rather use those languages that fit each of the tasks best. In contrast to polyglot programming, which on the surface advocates a similar approach, language-oriented programming explicitly encourages developers to build their own DSLs, or to extend existing languages with domain-specific concepts as part of the approach. To make this feasible, language workbenches such as MPS are an important ingredient of the language oriented approach.
With MPS you can define a custom editor for any new language to make using DSLs simpler. Even domain experts, who are not familiar with traditional programming, can work easily in MPS, with domain-specific languages designed with their own domain-specific terminology.
In the following video you can see an example of how an Interactive voice response (IVR) was made with MPS. This DSL is targeted at non-technical people so the user experience is adapted to them.