One reason for using a Domain Specific Language is to separate the business rules from the complexities of designing the system. When done correctly, the business rules can be maintained by business users who are the most familiar with the problem space. To a business user a DSL should be no different than a group of phrases that describe the rules for running the business correctly.
A well designed Domain Specific Language will appear as Descriptive And Meaningful Phrases.
In my previous post I described a DSL designed for running a poker room. I defined the syntax of the DSL as:
if the '$5-$10 Limit' list is more than 12 then notify the floor to openIn the example I defined a
bubble method that created methods for each member of the list passed to bubble. Each method that was defined by bubble took one value and returned the same exact value. This allowed the DSL to be verbose enough that not every word was required to have meaning. In fact 'the', 'list', 'is', 'than', and 'to' are all bubble methods. Without bubble methods the DSL can be DRYed out to read:notify floor open if '$5-$10 Limit' more 12However, the meaning of the business rule has been lost at the expense of removing the duplication.
As businesses change, their software requires changes also. By providing a meaningful syntax such as
"if the '$5-$10 Limit' list is more than 12 then notify the floor to open" the software can be altered by poker room managers, casino executives, or anyone well educated on poker room management. However, with every word that is removed the message becomes less descriptive and thus less maintainable. A sure sign that there is room for improvement is when a DSL requires training to understand. An ideal DSL contains phrases that are descriptive and meaningful enough that they require no explanation at all.
Who will be writing the code? Developers or business folk?
ReplyDeleteHow are the bubble methods meaningful? What is the meaning behind "the"? It looks like there is no meaning. I would think you run this risk of having a developer think the bubble methods are required, or have special meaning, when really they're just empty.
Isn't a maxim of DSLs that they tend toward conciseness?
In this instance I'm talking about a DSL designed so that "the business rules can be maintained by business users".
ReplyDeleteThe bubble methods were for when "not every word was required to have meaning". They do not have meaning, but they allow the entire phrase to be more meaningful.
I have the opinion that you should not trade readability for conciseness in this instance.
I'm going to nit-pick, because you don't want to dumb down the language for every domain. For instance, suppose you wanted to define a DSL for drawing graphics. Would it fit the domain better to say:
ReplyDelete"draw a line from 0,0 to 1,0"
Or would it fit the domain better to say:
"line 0,0 -> 1,0"
I would argue that the correct design for a DSL depends on the D. Otherwise they would be called SL.
I agree that the syntax is context specific. However, I think the context is the user not the domain.
ReplyDeleteUsing your example, the first (more verbose) version could be a better fit for a Project Manager designing a burndown chart. However, the second is clearly better for a programmer.
Another thing to note is that if the DSL had bubble methods for 'draw', 'a', and 'from' you could use both:
draw a line from 0,0 to 1,0
and
line 0,0 to 1,0
In my opinion bubble methods don't 'dumb down' the DSL. In fact, when reading the first more verbose example I know that I'm drawing a line from 0,0 to 1,0. Reading the second line doesn't as clearly convey the same message.
Another example is the DSL:
credit Platinum 10.dollars, slots 200
credit Gold 5.dollars, slots 200
credit Silver 2.dollars, slots 200
The above DSL could be easily understood by a casino host. But, it still requires processing to understand. But the following DSL can be easily understood by anyone, including a host that was just hired by the casino today.
credit Platinum guests 10 dollars after they reach 200 slot points
credit Gold guests 5 dollars after they reach 200 slot points
credit Silver guests 2 dollars after they reach 200 slot points
Jay,
ReplyDeleteFirst, I'm learning a lot from this and your previous posts on the subject. Thanks.
Your last example of the Casino dealer is interesting because you have a real user who would understand the concise statement (the first one) who is actually in that domain, but then favor the de-pithyfied syntax so anyone can read it.
I think this gets to the problem I see with it: if you allow the user to put words in there that the machine will interpret as noise, how will the user of the system know that? How will he/she know which words are not meaningful to the system? If you relegate articles of speech as just noise, I can understand this, but your last example uses "draw" as noise which seems to be a fairly specific and potentially meaningful (to the system _and_ user) word.
Why not catch ANY word the business user codes in method_missing and let it be noise if it is not found? Otherwise, the lists of bubble words will seem arbitrary.
I agree that 'draw' is meaningful in the previous example. I was responding to the comment from anonymous where 'draw' was removed and was trying to state that even if it didn't carry any value I thought it was valuable to have.
ReplyDeleteOn the topic of using method missing, it's a way to go. The up-side would be supporting any 'noise'. I'm not sure what all the potential side effects are. One is that methods such as 'floor' and 'open' are defined and wouldn't go to method_missing. They would instead cause a syntax error. I think it's an idea worth exploring though, give it a try.
DSL's benefits to non-programmers are unproven.
ReplyDeleteBTW, it is funny to see programmers arguingg about DSL's for non-programmers. Shouldn't this be just another agile story pulled directly from the customer that becomes an executable test case?
DSL's evolve to compress knowledge. They are not always widely agreed upon in large, international, multi-disciplinary, scientic domains where discovery is a primary activity. Just look at all the ontolgies for annotating genetic sequences. This requires a layer of mapping ontologies to make systems work together. And, when the ontology evolves, semantics must be remapped locally and by exogenous mapping ontologies. This is probably the extreme case.
I have not seen a DSL written in ruby provide meaningful grammer or syntax checking. If an End User was to write rules using a DSL, how would they 'debug' an erroneous sentence?
I think we have a long way to go before DSL's offer non-programmers the same degree of ROI.
-jherber
First off, thanks for the comment.
ReplyDeleteDSLs are quite unproven; however, my last two projects have been working on non-programmer DSLs. The primary intention of these blog entires is to list the experiences while working on these projects.
While I think there is some truth in your statements, I think you are also being a bit extreme. The applications I worked on had syntax and grammer checking that was sufficient for the non-programmers using the application. I've written a bit about the syntax checking already.
It's cool to disagree; however, you shouldn't dismiss it easily, especially when others are successfully doing it.
Targetting non-programmers with DSLs is the absolute right approach to take. The DSL should be as descriptive and meaningful as possible in the chosen domain. Thus, as you state, anyone familiar with the domain can grok it. Also, they could come back days of months or years later and still understand:
ReplyDelete"draw a line from 0,0 to 1,0"
I don't think that you can say the same for:
"line 0,0 -> 1,0"
This might leave them thinking...just what did the '->' symbol mean again?!
Anyway, awesome work Jay. You should really write a book on this stuff. I believe that DSLs are a large part of the future of software development.
Your work on the embedded variant is fascinating.