Recently I’m seeing a lot of discussion from people that believe that Domain Specific Languages (DSLs) are nothing more than glorified Application Programming Interfaces (APIs). In fact, a lot of this debate is put across in a derogatory tone:

“Hey kids, stop playing with your DSL toys and step into the real world. Here we just call them APIs”.

For me, this highlights what I’m seeing to be an increasingly growing divide - that between people that think of programming as formalising functionality and the people that think of programming as communicating process.  Both are equally valid views of the world and both viewpoints afford us with useful ways of thinking about the work we do on a daily basis.

As a very brief aside it’s important to say that in this article when I say DSL I’m actually mean internal DSLs - something written in a host language. For more discussion on this formalisation see http://www.martinfowler.com/bliki/DomainSpecificLanguage.html.

From a very high level perspective, both DLSs and APIs can be described as interfaces. Let’s call them language interfaces and programming interfaces. You might even argue that DSLs are typically an interface between software and a person, and APIs are typically an interface between software and software. However, this categorisation is remarkably bipolar; we’re increasingly seeing DSLs used for software to software interfaces and APIs still have to be read and understood by the humans connecting the software components together.

For me, a better distinction to make is the following:

“APIs focus on functionality, internal DSLs focus on communicating the functionality.”

This means that the programming as formalising functionality crowd will tend to see DSLs as unnecessarily wordy and complex APIs and the programming as communicating process will tend to see APIs as unreadable and unfriendly DSLs.

It doesn’t have to be this way. In fact both can co-exist perfectly happily. There’s no reason an API can’t do what it does best - formalise a particular set of functionality - and then it’s perfectly feasible to build a set of DSLs which sit on top of the APIs to communicate that functionality to different audiences each with their own focus and vocabulary.

I’d therefore like to ask people to stop the infighting. Discussion regarding the usage of specific terminology is important, sure. However I believe the term DSL is here to stay and although in many cases they may be functionally similar to APIs that’s not the point.

The point is that DSLs invite programmers to consider programming as communication and that’s a very good thing.