For several months now I've been working on a system where the business rules are expressed in a Domain Specific Language. In fact, the majority of my focus these days goes towards working with Domain Specific Languages. However, I'm most fascinated by Domain Specific Languages that empower business subject matter experts.
One problem with DSLs is that almost anything can be considered a DSL. Everyone knows the common DSLs: YACC and spreadsheet macros. However, recently Rake and Ruby On Rails have gained much popularity as DSLs. Some even consider Cobol to be a DSL. And there lies the problem, you can make a case for almost anything to be considered a DSL.
Is that a problem? Well, to me it is. I enjoy writing, talking, and thinking about DSLs. And, when I can't be specific about what I'm discussing I find my conversations often get slowed down by describing what type of DSLs I'm not talking about. Or, worse, people dismiss the conversations because they don't believe that DSLs can work in the way described. This, unfortunately, is fairly common because of DSLs of the past that have failed.
By now I hope you can understand why I feel the need to classify the type of work I'm doing. For the past few months I've been referring to my work as Business Domain Specific Languages. Unfortunately, even if you prefix business on a topic all anyone really hears is DSL. Also, (as Jeremy Stell Smith pointed out) the DSLs I'm interested in are similar to natural language.
Therefore, in an attempt to focus the conversations and make them more productive I'm going to start describing the type of DSL work I'm doing as Business Natural Languages.