Most of our software logic is written in our programming languages, these give us the best environment to write and evolve such logic. But there are circumstances when it's useful to move that logic into a data structure that our imperative code can interpret - what I refer to as an adaptive model. Here I'll show some product selection logic in JavaScript and show how it can be refactored to a simple production rule system encoded in JSON. This JSON data allows us to share this selection logic between devices using different programming languages and to update this logic without updating the code on these devices.

This is my usual DSL intro talk, but done with a twist as I'm talking to a much more DSL-aware crowd than usual. So essentially I twisted into a talk about how I introduce DSLs to people.

A Microsoft Channel 9 interview of me, my colleague Neal Ford, and Jeffery Snover (creator of PowerShell). The general topic is that of DSLs - Neal and I had just finished a tutorial on the topic at JAOO 2008 and had some good conversations with Jeffery.

When I attended DSL DevCon, Microsoft's Channel 9 dragged me off to be interviewed by Chris Sells.

A keynote for The Server Side Java Symposium that I gave with Neal Ford. We look at the growing movement towards Domain Specific Languages, what kinds of languages exist and why they are interesting. If you're looking for one talk on the subject then my preference is for the JAOO video, but this one expands on some of the themes and is more entertaining due to Neal's presence. It would also work fine audio only, if you can find a way to extract the audio stream.

I'm joined by Thoughtworks CTO Rebecca Parsons, who was a contributer to the DSL book, to talk with Markus Völter about DSLs. We talk about what DSLs are, the differences between internal and external DSLs, and when you should (and shouldn't use DSLs).

Will DSLs allow business people to write software rules without involving programmers?

When people talk about DSLs it's common to raise the question of business people writing code for themselves. I like to apply the COBOL inference to this line of thought. That is that one of the original aims of COBOL was to allow people to write software without programmers, and we know how that worked out. So when any scheme is hatched to write code without programmers, I have to ask what's special this time that would make it succeed where COBOL (and so many other things) have failed.

Frequently I come across the claim that some technology will allow users to write their own software and not need programmers any more. When I hear this I like to remember that this was the aim COBOL - and we know how that worked out.

I was asked to put together a discussion of DSLs for non-technical types. Maybe I've been reading too much Stephen O'Grady, but I felt an irresistible urge to do it in a Q and A manner. So here it comes.

The basic idea of a Domain-Specific Language (DSL) is a computer language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem. Domain-specific languages have been talked about, and used for almost as long as computing has been done.

When the topic of DomainSpecificLanguage comes up, one of the common puzzles is exactly what is or isn't a DSL. The trouble is that there is no precise definition for a DSL and there is a large gray area between DSLs and other things.

One of the tricky things about writing about external DomainSpecificLanguages is that I'm walking through territory already heavily tracked by the programming languages community. Programming language research has always been a popular area of academic activity, and I'm the first to admit that I don't have anywhere near the depth in this topic as many people who've been studying in this space for years. So inevitably the question comes up as to why such a noob as me thinks he can write a book in this well trodden ground?

One danger that DSL advocates need to guard against is the notion that first you design a DSL, then people use it. Like any other deice of software, a successful DSL will evolve. This means that scripts written in an earlier version of a DSL may fail when run with a later version.

In recent weeks I've been playing with, and looking at, compiler-compiler tools. A common feature of these tools is that they have a grammar file whose core is a description of the production rules of a grammar for a language. As well as describing the grammar, the file also provides information to the parser about how to process the language as it recognizes the language elements. In most compiler-compiler tools these instructions are represented as actions in the grammar - often these actions are encoded as as fragments of code in a high level language.

One of the problems with a FluentInterface is that it results in some odd looking methods. Consider this example:

I've been exploring various alternative languages and grammars for external DSLs. One of my main tools for this is Antlr. With this kind of exploration I have a project with multiple similar grammar files where I want to run essentially the same thing with different grammars. Although I only have a few grammar files at the moment, I could well end up with a couple of dozen.

A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example.

Given-When-Then is a style of representing tests - or as its advocates would say - specifying a system's behavior using SpecificationByExample. It's an approach developed by Daniel Terhorst-North and Chris Matts as part of Behavior-Driven Development (BDD). It appears as a structuring approach for many testing frameworks such as Cucumber. You can also look at it as a reformulation of the Four-Phase Test pattern.

Several years ago, my then colleague Matt Foemmel, dissatisfied with the tools with which we were building software, managed to get in touch with Charles Simonyi to find out more about the shadowy Intentional Software. What he saw impressed him, and he persuaded me and other ThoughtWorkers to get involved too. What we saw was a tool with startling potential, but we remained frustrated by the secrecy and lack of urgency to release. That frustration ended last week.

An internal DSL (often called an Embedded DSL) is a DomainSpecificLanguage that is written inside an existing host language. It's a common way of thinking in a number of programming language communities - particularly the Lisp community. It's now gaining a lot of attention as DSLs are a common way of thinking in the rapidly growing Ruby community.

Language Workbench is a term I coined in 2005 to describe a new class of software development tool, designed to build software through a rich environment of multiple, integrated, DomainSpecificLanguages. These tools are still quite a way away from being mainstream, but development on them continues and continues to be interesting. They are one of the few things I feel could significantly change the programming landscape.

When I wrote my recent article on Language Workbenches, I decided to separate the section on further reading into my bliki, to make it easier to report updates when new stuff appears.

I use the term lay programmer to mean someone who is programming without thinking themselves as a programmer. Someone who spends a large part of her day working on spreadsheets is doing programming, often very intense programming. Usually however she won't call herself a programmer, nor think of spending much time learning how to program better.

What is the connection between ModelDrivenSoftwareDevelopment (MDSD) and DomainSpecificLanguages (DSLs)?

It's pretty common to see the term “DSL” crop up in the context of MDSD. Indeed some MDSD people seem to think that DSLs only exist within the MDSD world. I've been writing a lot on DSLs recently for my book, but so far I haven't really touched on the MDSD angle much Instead I've concentrated on DSLs role in more conventional programming. DSLs exist in both the textual language and MDSD worlds and play pretty much the same role for both.

Sergey Dmitriev is one of the leaders of JetBrains, the people who gave us such wonderful tools as IntelliJ Idea and ReSharper. He's recently published an article on some exploratory development he's done called the Meta Programming System. He sees this system as an example of a broader movement which he calls Language Oriented Programming.

Model Driven Software Development (MDSD) is a style of software development that considers itself as an alternative to the traditional style of programming. The approach centers itself on building models of a software system. These models are typically made manifest through diagrammatic design notations - the UML is one option. The idea is that you use these diagrams, to specify your system to a modeling tool and then you generate code in a conventional programming language.

Oslo is a project at Microsoft, of which various things have been heard but with little details until this week's PDC conference. What we have known is that it has something to do with ModelDrivenSoftwareDevelopment and DomainSpecificLanguages.

I talk quite a bit with people about DomainSpecificLanguages these days and a common reaction I get to external DSLs is that it's hard to write a parser. Indeed one of the justifications for using XML as the carrier syntax for an external DSL is that “you get the parser for free”. This doesn't jive with my experience - I think parsers are much easier to write than most people think, and they aren't really any harder than parsing XML.

One of Ruby's most popular features is its support for metaprogramming, that is features that act like they change the language itself - introducing things like new keywords.

Should I use a Rules Engine?

A common phrase that's bandied about when talking about DomainSpecificLanguages (or indeed any computer language) is that of noisy syntax. People may say that Ruby is less noisy than Java, or that external DSLs are less noisy than internal DSLs. By Syntactic Noise, what people mean is extraneous characters that aren't part of what we really need to say, but are there to satisfy the language definition. Noise characters are bad because they obscure the meaning of our program, forcing us to puzzle out what it's doing.

XML has been around for a while now, and it's used a lot - indeed a lot more than it should be. Like most tools XML is good for some things and not for others