I also agreed with this until very recently. Jumped into a new language and realized how language features can help shape great APIs.

DSL is more like a generalisation of config files.

Mose DSLs I encounter started as configs and tend to be inelegant because they're incidental rather than planned languages. I applaud thinking in terms of languages up front and exercising restraint to keep it to the bare minimum.

While that is one quite useful application of DSLs, they're certainly used more widely than config files. Care to expand further?

I said "generalisation". You're thinking I mean DSLs in a static way - where they compile to a single static structure that is like a configuration file. I am trying to redefine the term here instead, because it seems more appropriate.

Essentially what I am asking here is: where do we set the line between "scripts" and "configuration files"? Because scripts are simply configuration files with a tree-like structure as they represent programs.

Scripts "configure the execution paths of your program".

A DSL thus is just a configuration file with a set of rules of applying those tree-like structures to each other.

Scripts are definitely not configuration file.

I would say the line is Turing-completeness.

For me, DSL are half way between configuration files and scripts. If they are not Turing complete they are configuration languages. If they are, then they are programming language (with a specific use case).

And I think that it is usually a bad idea to have configuration files in Turing complete languages (with exceptions, it can certainly be done well).

>> Scripts are definitely not configuration file.

>> I would say the line is Turing-completeness.

>> For me, DSL are half way between configuration files and scripts

_you_ would say.

>> If they are not Turing complete they are configuration languages. If they are, then they are programming language (with a specific use case).

Or, you could say that DSLs are what they are: "Domain Specific Languages". Which means that can either be a set of static definitions a-la configuration file, or on another side they can be scripts.

All of these definitions fit really well the meaning of "Domain Specific Language".

The decision to bring a new language into the world is not one taken lightly. There are simply too many languages.

DSLs are nonetheless a "necessary" evil; Most languages are too narrow to be useful for everything, so anywhere you see a boundary in your language -- something that might be done better in another -- your code will be shorter, it will be faster, and you will make fewer bugs.

But what if we can create a language with no boundaries? That language would not need a DSL.

A good API (and the client to that API) is indistinguishable from a DSL

:)

I think it's worth demonstrating that more pedestrian approaches are insufficient before writing a new language. New languages can be worth the effort, but they are certainly expensive approaches, all things considered.