Domain Specific Languages and their Limitations

It seems that a lot of people are raving about the use of domain specific languages in Ruby these days-- where clever uses of eval, load, etc make normal Ruby code look like the language of the problem domain. Rails has a few good examples of this, such as ActiveRecord, which can be considered to be a DSL for describing data models.

It's really great to see these ideas becoming more mainstream.. However, I'm concerned that it's an idea that can be taken too far. Here's an example from Jay Fields:

if the '$5-$10 Limit' list is more than 12 then notify the floor to open

A business user can read this and think: This looks like English, I can speak English so therefore I can edit this with out a problem. Let me specify that this can only happen after 5pm:

if the '$5-$10 Limit' list is more than 12 and it is later than 5pm
then notify the floor to open

What happens then? most likely, the program will break with a strange error about "it" being undefined. The key issue is that we are only simulating English: in reality it is still Ruby, which has a strict syntax and requires methods to be defined before they are used. From an HCI perspective, allowing users to pretend to write English code gives them an illusion of freedom-- which can cause significant frustration if the expectation of freedom is not met. The only way I can see around this is to make sure that the users of the DSL understand the basics of programming languages and are trained to understand the limitations of their particular DSL. I'd be interested to hear about how Jay and his team are dealing with these issues.

In the long run, I don't think the main value from DSLs will come from allowing non-techincal users to encode business rules, but instead in helping programmers make their programs more DRY. The best examples of DSLs from the Ruby world, such as ActiveRecord, Rake and Capistrano all fall into this category.