Friday, September 28, 2007
What is a Domain Specific Language?
At JAOO I had a number of interesting discussion with various folks involved in DSLs (Simonyi, Fowler, Czarnecki) and as consequence I refined my definition of what a DSL is. I remove the terms "abstract" and "business". Here's my new try:A DSL is a concise, precise and processable description of a viewpoint, concern or aspect of a system, given in a notation that suits the people who specify that particular viewpoint, concern or aspect.
Of course there are still the usual points you can make about a DSL: textual vs. graphical vs. whatever, DSL vs. readable API, internal vs. external and interpretation vs. generation.
I think, however, that the definition above captures the essence.
Opinions? permalink
Comments:
<< Home
Very good!
I like the term 'business' being removed. Talking about "business"-DSLs like talking about the holy grail is soo boring. We are constructing software systems so our DSLs are used to describe such systems (at least in 90% of all cases).
It's not that I miss it but why don't you like the term 'abstract'?
I like the term 'business' being removed. Talking about "business"-DSLs like talking about the holy grail is soo boring. We are constructing software systems so our DSLs are used to describe such systems (at least in 90% of all cases).
It's not that I miss it but why don't you like the term 'abstract'?
well, DSLs might be described to describe the business viewpoint/concern/aspect, but that's by no means all that can be described via DSLs.
I removed abstract because it is one of these over-used terms and in the current definition it is not necessary.
I removed abstract because it is one of these over-used terms and in the current definition it is not necessary.
I like this! I keep looking for a good definition for a DSL. Starting with your definition, I might even suggest removing a few more words to try to get something as tight as possible:
1. I'd suggest that if it is processable, it is precise, so we might be able to remove "precise" from the description.
2. I'd love to replace "viewpoint, concern or aspect" with a single term. Aspects are often described as cross cutting concerns which would suggest they're a subset of concerns. A viewpoint is somewhat different, however, as you could conceivably have multiple views of the same concern. However, while viewpoints don't necessarily correlate to concerns, I think it might be reasonable (if only for the sake of conciseness) to suggest that any given DSL could be said to focus on a specific concern.
We'd then have something like:
"A DSL is a concise, processable description of a concern of a system, using a notation accessible to the people who specify that concern."
I'm tempted by "compilable" (or machine processable) to replace processable as that doesn't exclude a language that can only be adequately processed by the human brain. I'm also concerned about associating a DSL to a specific notation as I think the trend in DSLs is to think about various projections of an underlying DSL and to consider the DSL independently of the notations/projections being used to edit it at a given time.
But then maybe that's a little too much thinking for now!
Best Wishes,
Peter
1. I'd suggest that if it is processable, it is precise, so we might be able to remove "precise" from the description.
2. I'd love to replace "viewpoint, concern or aspect" with a single term. Aspects are often described as cross cutting concerns which would suggest they're a subset of concerns. A viewpoint is somewhat different, however, as you could conceivably have multiple views of the same concern. However, while viewpoints don't necessarily correlate to concerns, I think it might be reasonable (if only for the sake of conciseness) to suggest that any given DSL could be said to focus on a specific concern.
We'd then have something like:
"A DSL is a concise, processable description of a concern of a system, using a notation accessible to the people who specify that concern."
I'm tempted by "compilable" (or machine processable) to replace processable as that doesn't exclude a language that can only be adequately processed by the human brain. I'm also concerned about associating a DSL to a specific notation as I think the trend in DSLs is to think about various projections of an underlying DSL and to consider the DSL independently of the notations/projections being used to edit it at a given time.
But then maybe that's a little too much thinking for now!
Best Wishes,
Peter
Good to see someone attempting this tricky task! What about the existing, widely-used definition by Arie van Deursen et al. (http://homepages.cwi.nl/~arie/papers/dslbib/):
"A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain."
In Markus' definition, the main problem is that a DSL is described as a "description" of a system. That's the model, not the language - and you get a rap on the knuckles for mixing meta-levels ;-).
I'd agree with Peter that "viewpoint, concern or aspect" is too long-winded - especially if it's going to be repeated.
Saying that the _notation_ suits a particular group of people is rather weak. The main thing is that the language _concepts_ and structures map well to the problem domain. As Peter says, notation is a secondary, if important, concern. I'm not sure it can be separated out of the definition though, since a language includes both abstract and concrete syntax.
Also, saying the language should suit a group of people is tricky: they won't necessarily agree, if they're used to some older format (even if it's not as good). "suits" implies their agreement, not just that it would be good for them. Perhaps better is to say that the language suits a particular problem domain.
"A domain-specific language (DSL) is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain."
In Markus' definition, the main problem is that a DSL is described as a "description" of a system. That's the model, not the language - and you get a rap on the knuckles for mixing meta-levels ;-).
I'd agree with Peter that "viewpoint, concern or aspect" is too long-winded - especially if it's going to be repeated.
Saying that the _notation_ suits a particular group of people is rather weak. The main thing is that the language _concepts_ and structures map well to the problem domain. As Peter says, notation is a secondary, if important, concern. I'm not sure it can be separated out of the definition though, since a language includes both abstract and concrete syntax.
Also, saying the language should suit a group of people is tricky: they won't necessarily agree, if they're used to some older format (even if it's not as good). "suits" implies their agreement, not just that it would be good for them. Perhaps better is to say that the language suits a particular problem domain.
Hi Steve,
good to see you join in on this :-)
"A domain-specific language (DSL)
is a programming language or
executable specification language
that offers, through appropriate
notations and abstractions,
expressive power focused on, and
usually restricted to, a
particular problem domain."
what I don't like about this one is the focus on "executable" and "programming". In fact, I think that DSLs need not be executable. They have to be precise, but not executable. Also, I miss the idea of a DSL only describing a particular concern.
> In Markus' definition, the main > problem is that a DSL is
> described as a "description" of
> a system. That's the model, not
> the language - and you get a rap
> on the knuckles for mixing meta-
> levels ;-).
well, of course you're right -- but of course it was intended differently.
> I'd agree with Peter that
> "viewpoint, concern or aspect"
> is too long-winded - especially
> if it's going to be repeated.
I agree, too, but I didn't know
what to write. You and Peter convinced me to just use concern.
> Saying that the _notation_ suits
> a particular group of people is
> rather weak. The main thing is
> that the language _concepts_ and
> structures map well to the
> problem domain. As Peter says,
> notation is a secondary, if
> important, concern. I'm not sure
> it can be separated out of the
> definition though, since a
> language includes both abstract
> and concrete syntax.
sure. However, from the DSL user's point of view the notation is what he sees and thus, what counts. I really want to emphasize that.
> Also, saying the language should
> suit a group of people is
> tricky: they won't necessarily
> agree,
well, then let's break the group
into smaller groups who can agree,
and then have several languages.
So, here's another try:
A DSL is a concise, processable language for describing a specific
concern of a system. The abstractions and notations used are tailored
to the stakeholders who specify that particular concern.
Post a Comment
good to see you join in on this :-)
"A domain-specific language (DSL)
is a programming language or
executable specification language
that offers, through appropriate
notations and abstractions,
expressive power focused on, and
usually restricted to, a
particular problem domain."
what I don't like about this one is the focus on "executable" and "programming". In fact, I think that DSLs need not be executable. They have to be precise, but not executable. Also, I miss the idea of a DSL only describing a particular concern.
> In Markus' definition, the main > problem is that a DSL is
> described as a "description" of
> a system. That's the model, not
> the language - and you get a rap
> on the knuckles for mixing meta-
> levels ;-).
well, of course you're right -- but of course it was intended differently.
> I'd agree with Peter that
> "viewpoint, concern or aspect"
> is too long-winded - especially
> if it's going to be repeated.
I agree, too, but I didn't know
what to write. You and Peter convinced me to just use concern.
> Saying that the _notation_ suits
> a particular group of people is
> rather weak. The main thing is
> that the language _concepts_ and
> structures map well to the
> problem domain. As Peter says,
> notation is a secondary, if
> important, concern. I'm not sure
> it can be separated out of the
> definition though, since a
> language includes both abstract
> and concrete syntax.
sure. However, from the DSL user's point of view the notation is what he sees and thus, what counts. I really want to emphasize that.
> Also, saying the language should
> suit a group of people is
> tricky: they won't necessarily
> agree,
well, then let's break the group
into smaller groups who can agree,
and then have several languages.
So, here's another try:
A DSL is a concise, processable language for describing a specific
concern of a system. The abstractions and notations used are tailored
to the stakeholders who specify that particular concern.
<< Home