Relevance of Domain Specific Languages

I just read Brian Slesinsky's Weblog on Why most of us won't be inventing little languages. It is true because the languages nowadays are not equipped with the facility (except languages like LISP).

I feel that we need the combination of both; generic and domain specific (derivable from the generic language) languages. The flexibility should be present in a language to mold it into a domain specific language (as in LISP using Macros)

When we are developing a reasonably complex application we would want a domain specific language that we could create/change ourselves with ease. This would speed up the development and would help the thinking process. We may also want to "refactor" commonality into a more domain specific language as we go on.

The speed of development comes mainly due to the reduction in the amount of code that needs to be written in a domain specific language and the fact that it helps in thinking about the problem.

But as Brian said, if we are developing a library we would want others to understand and use it. Hence for an API you would want to provide a wrapper in the generic language. Majority of the developers usually try to understand just enough of a library to use it. The wrapper written in a generic/ well known syntax would serve just that.

For example, take the case of imaging..
A domain specific language, in which we can specify transformations, kernel operations, etc., would enable the API developer to add huge amounts of functionality very quickly. On top of it if she adds a wrapper for developers to make direct calls, it would be easy to use.

Anyone who wants to dive deeper and change things would have to understand the domain specific language but that is the price one has to pay for getting so much functionality/ bug-fixes so fast. However the core part would be very concise than if it were to be written in the generic language.
Another way is to "expand" the code written in domain specific language to a readable, generic language.