On Aug 31, 2006, at 6:08 AM, Ramon Leon wrote:

>> As I understand it, the term embedded DSL already refers to
>> DSLs that are created by bending the syntax of an existing
>> language--basically making a new language from building
>> blocks of an old language. The other sort (external DSL) is
>> where you use yaCC or smaCC or something similar to build
>> actual parsers/compilers.
>
> Agreed.

Just to argue with myself, I took another look at the Martin Fowler  
article (http://www.martinfowler.com/bliki/ 
DomainSpecificLanguage.html), where I first saw the embedded/external  
distinction. I thought it was crystal clear--but on reading it again,  
I'm not sure.

Does the embedded/external distinction just capture the no-parser/ 
parser division? Or is embedded DSL intended to mean something more  
like Paul Graham's Bottom-up programming (http://www.paulgraham.com/ 
progbot.html)? I had always assumed it was the no-parser/parser  
split. But the description is ambiguous. If this technique must be  
given a name, I prefer the name bottom-up programming.

>> I'm still interested in an embedded DSL.
>> However, I'm not convinced that simply altering an existing
>> language so it is closer to the domain should count as a DSL.
>
> That's the very definition of DSL.

I don't like that definition. In my mind, simply moving a language  
closer to the problem domain is just basic software engineering  
(maybe that says a lot about my views on software engineering--and  
probably explains why I like Lisp/Ruby/Smalltalk so much).

Moving closer to the domain is necessary for a DSL, but it isn't  
sufficient.

Having thought about it more, here's the crux of the issue for me. To  
be a DSL it must be (first and foremost) a language in its own right.  
You must be able to distinguish it from the host GPL (general  
programming language). The DSL may not have a name, but it must be  
nameable. You must be able to point to a chunk of code and say, "This  
is written in BlahBlah".

Let's say programming fundamentalists capture me and force me to  
write applications in C. To survive such harsh conditions, I write an  
excellent library, RichBrillanceDSL. Now, I write the rest of the  
application using this library. To me, this doesn't count as a DSL.  
I'm not writing in RichBrillianceDSL, I'm still writing in C using  
RichBrillianceDSL.

On the other hand, if I'm making a Rails web page, and I write an RJS  
template, RJS is a domain specific language. It is clearly separate  
from the Ruby code used in the application's controller. The file has  
its own extension and everything.

To really pick at semantic nits, you shouldn't call bottom-up  
programming a DSL.  Even though it's been highly tuned for a given  
domain, it is still (by definition) a general purpose language. The  
language is still turing complete, and you can still use it to solve  
any general problem (or at least any problem solvable with a GPL).

Of course, I think banishing all turing-complete languages from the  
ranks of DSLs is a bit of an over-reaction (after all, it may be  
possible to misuse an embedded DSL to execute arbitrary code--even if  
that wasn't the original intention), but I do think DSLs need the  
general sense of limited usefulness. A DSL should be highly focused.  
It should only be good at one thing.

The Pragmatic Programmer book has an interesting example:

They recommend creating a mini-language for the sole purpose of  
communicating with the client. Originally, this language will not be  
executable. It is just a simple way for the client to express their  
requirements.

However, once the specifications are in place, you could go the next  
step and turn the specifications into executable code.

That's very different from the bottom-up approach.

-Rich-