The hype comes and goes, but they always have and always will be, in one form or another. But they don't always get called DSLs. Put the idea in your toolbox,

The hype comes and goes, but they always have and always will be, in one form or another. But they don't always get called DSLs. Put the idea in your toolbox, and use where appropriate. Call it a DSL or something else based on what is currently cool. Good programmers have long known that you should build your language up towards your application, and then write your language within that language. What tools are available to do that and where the line is drawn will vary. But you'll find customized languages buried in your database (SQL), configuration languages like https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl, specialized build configuration languages like make or ant, regular expressions for text matching, and so on. Some languages encourage building external languages that you then parse and act on. Others encourage customizing an existing language to your needs. (Our Glorious Leader published a book in the mid-90s on doing that with Lisp, see http://www.paulgraham.com/onlisptext.html http://www.paulgraham.com/onlisptext.html for details.) There have even been languages which are designed to be easily implemented in other languages, with whatever customizations you want. For example I personally worked with code from the 1980s that implemented a Forth variant to write financial models in. But the idea doesn't have to be literally a new language. Squint sideways at any API, object model, or library and you can see it as a language. Conceptually there is a close parallel between scripting web services, and writing a TCL script that uses prebuilt commands written in C. If you can see the parallels and see how principles from the one apply to the other, the odds are that you'll be doing both better. Whereas if you don't see it and reinvent the wheel from scratch, you're going to wind up learning lessons the hard way that were learned many, many years ago. All that said, writing and maintaining a language is significantly harder than writing business code. Therefore you'll always see rather more people writing code in languages, than writing languages to make code easy to write.