Purely declarative DSL
Let us assume that we need to build a quote generation program. This mean that we need to generate a quote out of the customer desires and the system requirements.
The customer's desires can be expressed in this UI:
The system requirements are:
- The Salary module is specification is a machine per every 150 users.
- The Taxes module requires a machine per 50 users.
- The Vacations module requires the Scheduling Work module.
- The Vacations module requires the External Connections module.
- The Pension Plans module requires the External Connections module.
- The Pension Plans module must be on the same machine as the Health Insurance module.
- The Health Insurance module requires the External Connections module.
- The Recruiting module requires a connection to the internet, and therefore requires a fire wall of the recommended list.
- The Employee Monitoring module requires the CompMonitor component
The first DSL that I wrote for it looked like this:
if has( "Vacations" ): add "Scheduling" number_of_machines["Salary"] = (user_count % 150) +1 number_of_machines["Taxes"] = (user_count % 50) +1
But this looked like a really bad idea, so I turned to a purely declarative approach, like this one:
specification @vacations: requires @scheduling_work requires @external_connections specification @salary: users_per_machine 150 specification @taxes: users_per_machine 50 specification @pension: same_machine_as @health_insurance
The problem with this approach is that I wonder, is this really something that you need a DSL for? You can do the same using XML very easily.
The advantage of a DSL is that we can put logic in it, so we can also do something like:
specification @pension: if user_count < 500: same_machine_as @health_insurance else: requires @distributed_messaging_backend requires @health_insurance
Which would be much harder to express in XML.
Of course, then we are not in the purely declarative DSL anymore.
Thoughts?
Comments
Oren,
what's the point in adding second "language" with some cryptic syntax (along with all the disadvantages of DSL and its coupling with the code) to the development project, when you already have .NET at your hands?
Rinat,
Please check previous discussion on this in this blog.
Broadly, flexibility, clarity, simplicity.
Oren,
And what about the efficiency?
I've just posted a simple .NET code that does exactly the same things as your samples for the DSL book. And yet it took me just a little bit of time to write that (as opposed to spending some resources to write and maintain separate DSL).
http://rabdullin.com/how-to-implement-dsl-functionality-efficiently/
Rinat,
Efficiency? It compiles down to the same IL.
I don't see the point, frankly.
The code the is required to build this is around 150 lines, is supports runtime updates, drop & go approach and is very easy to follow.
Time to write this: 1.5 hours, mostly spent writing the explanation in the book.
Just to be clear, are you aware that those DSL samples are using the Boo language? And that Boo is a fully fledged CLR language?
Oren,
yes, you were right, I was not aware of the Boo's existence. Given that some of my arguments are obsolete.
And yet those arguments remain:
Why do you need to use another language if .NET can do the same?
Boo + .NET development feels to be less efficient than pure .NET development, since in the last case you do not have IDE support (IntelliSense + support), there's an extra tool in the stack to handle (that complicates build and integration scripts, there are more naming and usage guidelines to document and follow)
PS: What is the drop-n-go approach?
drop& go refers to just dropping a script in a directory and getting the new functionality.
1/ Because the language is flexible.
2/ There is an IDE for Boo, if this is required. I tend to write short DSL scripts, which rarely need this, though.
As for the extra tool, it allows you to work at a higher level, with a lot of help from the language. It is a good tool
Oren,
Hm, I just cannot imagine development level that so high that the Boo can handle more efficiently than .NET. (not only DSL)
Could you show an example of that, please?
First of all, Boo is .Net.
The ability to modify the language itself to fit our needs is extremely powerful.
Check the Domain Specific Language category in this blog for more details.
Brail, Rhino ETL, Bake, etc are all such examples
Oren,
I do not think that Boo is .NET, since .NET SDK does not contain tools to compile Boo scripts.
Still, what's the example of language modification that Boo can handle much more efficiently than the latest C#?
Rinat,
Boo is a language that compiles down to IL and run on the CLR.
It is not included in the .NET SDK, but neither does a lot of useful things.
Limiting yourself to the .NET SDK is a bad habit.
As for the advantages, they have been discussed in this blog extensively in the past, check the DSL category
Oren,
Ok, this Boo/.NET SDK turns out into more of a HW.
I guess that with the proper logical organization of the solutions the difference in efficiency between these two will turn out to be marginal (especially when development resources are not limited).
Although I'll keep an eye on the lookout of the user stories that could not be not be efficiently leveraged by plain .NET.
Thanks for the dispute.
HW?
"Holy War"
Wow, can't wait to see your book.
I like the drop-and-go approach. I am solving a field mapping problem (very similar to functoids in BizTalk, if you know what I mean). Basically business users can map fields and generate reports/files the way they want. I am thinking about using DSL for that purpose. Boo looks easy enough, but I want to use ANTLR to create my own DSL.
Anyway, your posts give me a lot of inspirations.
Thanks,
SQL is declarative, functional languages are. if your sample doesn't imply line-by-line execution, it might be too. are you talking about programming languages or data? (then again, given don box's weird talk at lang.net, we might be up to replace programming with XML altogether, only he understands that some would rather not write so many angle brackets...)
Comment preview