Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,549

filter by tags archive

Purely declarative DSL

time to read 2 min | 291 words

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
		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.



Rinat Abdullin


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?

Ayende Rahien


Please check previous discussion on this in this blog.

Broadly, flexibility, clarity, simplicity.

Rinat Abdullin


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).


Ayende Rahien


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?

Rinat Abdullin


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:

  1. Why do you need to use another language if .NET can do the same?

  2. 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?

Ayende Rahien

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

Rinat Abdullin


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?

Ayende Rahien

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

Rinat Abdullin


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#?

Ayende Rahien


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

Rinat Abdullin


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.


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.


Stefan Wenig

Of course, then we are not in the purely declarative DSL anymore.

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

Comments have been closed on this topic.


  1. The worker pattern - 3 days from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats