Ayende @ Rahien

It's a girl

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:

image

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

Rinat Abdullin
01/30/2008 03:14 PM by
Rinat Abdullin

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?

Ayende Rahien
01/30/2008 03:29 PM by
Ayende Rahien

Rinat,

Please check previous discussion on this in this blog.

Broadly, flexibility, clarity, simplicity.

Rinat Abdullin
01/30/2008 05:19 PM by
Rinat Abdullin

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/

Ayende Rahien
01/30/2008 05:35 PM by
Ayende Rahien

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?

Rinat Abdullin
01/30/2008 06:00 PM by
Rinat Abdullin

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:

  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
01/30/2008 06:22 PM by
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
01/30/2008 06:48 PM by
Rinat Abdullin

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?

Ayende Rahien
01/30/2008 06:56 PM by
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
01/30/2008 07:46 PM by
Rinat Abdullin

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

Ayende Rahien
01/30/2008 08:38 PM by
Ayende Rahien

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

Rinat Abdullin
01/30/2008 09:24 PM by
Rinat Abdullin

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.

Harry
02/01/2008 01:54 PM by
Harry

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,

Stefan Wenig
02/01/2008 08:39 PM by
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...)

Comments have been closed on this topic.