The first talk I went to was about Domain Specific Languages

We started with introductions and experience. No one knows anything about DSLs.... great

Defining a DSL – We basically decided that a DSL was a language that can be used to describe a problem or domain. Whether this is for the business user or the programmer is a debate I do not think we will solve.

Good examples of DSLs we use: Outlook rules engine is a very good example. Another one was searching where we can use quotes and other symbols to narrow our search.

Testing a DSL is hard. Quote someone mentioned “you are asking a user to change production code.... read that sentence again” (attributed to Jeremy Miller)

Fowler is using ANTler to parse these languages. There is apparently a .NET implementation

Some things might take the DSL and parse & compile it to code

Scott Guthrie: “if you create a DSL and leave how easy is it for someone to take it over. Are we leaving a nasty legacy”

Fowler: “A DSL is just a veneer over an API”

Guthrie: “make sure you are not re-inventing the wheel (i.e. creating your own file format when an existing one is out there)”

Nhibernate mapping is also a good sample of a DSL. XML is not the greatest way to do it... but it works

There is the possibility of creating DSLs in Boo. I do not know anything about Boo though.

Fowler:  You will usually have more than one DSL in a solution. You will not have just one DSL that solves everything.

DSLs drift into a general domain. I.e. ANT now does everything, sendmail has drifted to do more than it was intended as well

The holy grail is to use DSLs to communicate between users. It is hard to achieve but well worth it if it can be done

With an external DSL. As changes happen then code needs to change. Do you maintain backwards compatibility? IF the language changes, the parser needs to changed

Fowler: If this happens then you have control over the parser/compiler so you can change it to output properly

Uncomfortable silence

We discussed defining DSLs a bit more and also the issue of code maintainability but that always came back to that it is just the same as maintaining an API.

I had really gotten what I wanted out of the talk so I moved over to the end of “becoming a catalyst for change” which was an interesting debate about trying to drive passion into developers.

One really good point was that ALT.NET has no coupling to Agile. Granted most people here are agile developers but you do not have to be an agile developer to be an alt.net developer (and that we should rename alt.net to options.net or something else as this whole thing is about options that we can use).