I’ve followed Infoq’s post on Michael Feathers’ text about programs that try to get closer to English.

Recently, another meme has been on the rise. The meme I’m talking about is the notion that code becomes better as it approaches English. I’m seeing this in a couple of different places now. One is the Domain Specific Languages community. While it’s true that DSLs don’t have to become English-like, there are a quite a few people who try.

Michael goes on working on examples from popular libraries and ends up diving text understanding in two types”: narrative and symbolic.

In the narrative mode, we are approach text like prose and read through it the way we would read through English or any other natural language - it tickles the verbal centers of our brain. The symbolic mode is more visual.

I think that this classification works for programming languages in general but I’m afraid that that’s not the case when it comes to Domain-Specific Languages.

In general-Purpose Languages getting closer to English is generally on way to create a Humane Interface, generally is done through Fluent Interfaces. Domain-Specific Languages won’t need this ‘readability boost’ because they’re already readable since they map domain concepts.

I always see Domain-Specific Languages somewhat as en evolution of Domain-Driven Design. In Domain-Driven Design you use objects to model the domain, using DSLs you give up on the objets and use actual domain concepts in your language.

The example about Behaviour-Driven Development tools is interesting. BDD frameworks are very generic and have a broad domain. Not all BDD tools are DSLs, those who are –like RSpec, always present in my examples- deal with the domain of specifications and verifications.

I would guess that the fact that RSpec uses such an English-like language is because we generally write functional specifications in English (or other language). The DSL reflects the domain; if the domain used to be expressed in plain natural language the DSL follows this style.

If we were writing a calculator using DSLs we probably wouldn’t write something like:

result.equals two.plus.three

But:

result = 2 + 3

When developing a DSL it is important to map domain’s concepts to language constructs, if this implies in having a natural-language-like syntax or not depends on the domain.