Whenever you listen to a discussion by experts in any domain , be it chess players, young mothers or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's partly what domain specific languages are about.
They're about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable and hopefully writable by domain experts.
DSLs that were targeted at software developers or scientists have been around for quite a time. The unix little languages found in configuration files or the languages created with the power of LISP macros are some of the older examples.
When talking about domain specific languages Martin Fowler makes the well accepted distinction between internal and external DSLs and language workbenches.
Internal DSLs are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for some languages who have more syntactic sugar (like Ruby or Scala) and much more difficult for others (like Java). Some people even see library APIs as a form of a DSL (but not a very fluent one). Most internal DSLs wrap existing APIs, libraries or business code and provide a wrapper for a less mind bending access to the functionality. They are directly executable by just running them. Depending on the implementation they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems or validate user input. There is a plethora patterns and idioms that helps you to bend your host language. Examples are: expression builder, method chaining, function sequence, object scoping, literal collection. The language can be developed in the constraints of the host language. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly together with a domain expert.
External DSLs are mostly textual expressions of the language, graphical ones are much more difficult to handle (especially in terms of versioning, storing in SCM and editing). The textual expressions are processed by a tool chain that includes lexer, parser, model transformer, generators and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. For working with external DSLs it has been helpful to define a grammar (e.g. using EBNF) which provides the starting point for generating parts of the tool chain (e.g. editor, visualizer, parser generator). For simple DSLs a hand made parser for instance using regular expressions may be sufficient but most often becomes quickly unwieldy. There are some tools for working with external DSLs - openArchitectureWare, ANTlr, SableCC, AndroMDA. Systems working with XML dialects as external DSLs are also quite common, although they are not easily processable by (nontechnical) people. ANT build scripts are a good example for that.
You must always take the target audience of your DSL into account. Are they developers, managers, business customers or end customers? You have to adapt the technicality of the language, the available tools, syntax help (intellisense), early validation, visualization and representation to the intended consumers. Using DSLs can help raising the level of abstraction and thereby hiding technical details behind well known syntax and semantics. It empowers users as it gives them the ability to adapt systems to their needs without requiring the help of developers. It also speeds up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available.
- Martin Fowler, DSL book (work in progress) 
- Venkat (DSLs in Groovy) 
- Markus Völter (MDD, oAW) 
- Thoughtworks DSL podcast  
- MDD, DSL podcasts of Software Engineering radio 
--Michael Hunger 13:10, 29 January 2009 (PST)