I feel the term has probably been overused. I like to consider a Domain Specific Language to be something that talks about [a] problem domain, such as configuring workflow to solve some business problems or […] something that is business related in the problem space. And I see a lot of us using Domain Specific Languages to solve programmer problems, which are really problems in the solution space.
[…]
What I want to use a DSL for is I want to be able to take a problem that a user comes to me and […] create a DSL that describes it. I don’t think that the business person needs to be able to write the DSL, but I should be able to write it in the DSL, show it to a business person and they can say: “Yes, that’s what I want” and it is something that is immediately obvious to them that it solves their problem domain. It’s Domain Specific Language and if it is not addressing a domain, the term DSL seems kind of loose for me.
[…]
So I think you can have libraries with good interfaces but that doesn’t necessarily make them DSLs, certainly dropping parenthesis off a library call doesn’t make it a DSL.
What a refreshing perspective.
This is the first time I have heard someone give a definition of “DSL” that is restrictive enough to have actual meaning. Later on he also gives a similarly reasonable definition of BDD, Behaviour-Driven Development. (His first statement? There’s no difference between BDD and TDD.)
[The transcript is kinda hidden; you need to click show all at the bottom of the inset frame to read it.]
