Lambda the Ultimate

I think there can be value in considering even simple configuration files and APIs as DSLs. The biggest benefit of thinking about APIs as DSLs is that it allows you to take advantage of all of the concepts for versioning, interacting models, refactoring of DSLs and the ideas of separating the concrete syntax from the abstract grammar and potentially supporting n-projections.

We have an in-house generator with a cms for editing metadata that is stored in a database, generated to XML (which is where we're working on formal transformation based approaches to grammar refactorings) and consumed by an API.

When you have an API, you're stuck with an API. When you have a DSL there are lots of potential concrete syntaxes that can be used for different use cases.

The LtU archives contain many discussions about API vs. DSLs. I suggest searching the archives with these two keywords. You'll find plenty of relevant stuff. (Use the google search, to include the "LtU classic" archive).

Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.

http://martinfowler.com/bliki/DslReadings.html

'I' in the API is the interface. 'L' in the DSL is a language. Language is surely an interface for communication. You can have application-specific programming language -- that's the subset of an API. When your API starts to be domain-specific, you are getting a DSAPI. I believe the difference between API and DSL here is just the last letter -- if you want to call your interface a language or not.

Here's my current informal view:

Language = syntax + semantics
API = data structure + operations

Syntax often reflects an underlying structure, and operations define legal transitions so in a sense, we can establish an equivalence of syntax == structure, semantics == operations; so languages are APIs and v.v. Many APIs are not very well-designed languages, because people don't make this connection, but it's always there.

Also, lifting an API to a real language is only an advantage when you're dealing with multiple abstractions rather than a single abstraction, as working in the host language's syntax is often sufficient for single abstractions. There's a high barrier to entry to creating a new language, hence all the interest in extensible languages/syntaxes, etc.

One way that I like to think of this, is to ask "what is the total number of distinct messages that can be produced by this API or DSL?" I tend to think of an API as having a limited and discrete number of messages, because this makes the interface testable. However a language has many more permutations of the messages that can be sent via the interface, so it is governed more by a set of rules about parts of the message. Somewhere along this continuum, where you measure the number of message permutations, I think is the dividing line between an API and a DSL.

Call me thick, but I could not find DSL in Camel. An API - yes, a DSL - no. My prime example of a DSL is R - a language created to tackle the difficulties of statistics and visualisation. Although AFAICT it has grown beyond it and is no longer a little language, but nonetheless, it has been created with a clear goal in mind and designed to facilitate the achievement of the goal in the best manner possible.

Although I am not Enterprise expert, but Camel calling itself route DSL seems to be a bit misleading - I expected it to be a request/request handler mapping, but it turned out to be a component connector (correct me if I'm wrong); from where I stand - quite powerful one.