As Martin Fowler states in his article — "The basic idea of a domain specific language (DSL) is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem."
Good examples of DSLs are all around us — SQL, HTML, XML, CSS, etc. These all serve their own purpose and have very limited use outside of their original domain. Because these languages define their own grammar and require dedicated parsers, we may call them external DSLs, meaning that they are unrelated to any other programming language, which would host them.
On the other hand, internal DSLs reuse the grammar and the parser of a host general purpose programming language. This obviously puts restrictions on the DSLs' grammar, however, saves the DSL creators from implementing a parser and ensures smooth integration of the DSL into the whole system.
Here's an example of a simple internal DSL use for account transfer operations, embedded into Groovy: "Account1" >> 350.eur >> "Account3"
This is the same operation encoded in the host language (Groovy) directly instead, which highlights the main advantage of using the DSL — readability.
DSLs are typically used to wrap business logic in an easy-enough syntax, which would clearly communicate the meaning of the code not only to developers, but also to domain experts.
DSL may also be used to provide nice and communicative interface to library or framework.
This is an example of using the Groovy's SwingBuilder, which provides an internal DSL to the Swing framework.