On Sep 1, 2006, at 6:16 AM, Ramon Leon wrote:

>> 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 consider bottom up programming, and embedded DSL's the same thing.

A lot of people do. However, I think there's a real benifit in  
distinguishing between  the following:

a) DSL as Bottom-Up Programming using language features
b) DSL as Bottom-up Programming using a full parser (and probably pre- 
processor)
c) DSL to interpret external strings using features of the host language
d) DSL to interpret external strings using a full parser.

The ability to process external strings (most often stored in files)  
is not entirely external to the DSL issue since:

a) The techniques used for bottom-up programming and for interpreting  
external strings can be significantly different.

b) bottom-up programming lets developers write code that is cleaner  
and easier to maintain. processing external strings can be used as a  
tool for developers; however, they are often used to allow end users  
to modify an application's behavior without opening and modifying the  
application directly.

Unfortunately, the term DSL seems to be used for all the above (and  
more), which really muddies any discussion. I see a fundamental  
difference (both in technique and in motivation) between bottom-up  
DSLs and interpreter DSLs. I wish common usage of the terms reflected  
that difference.

>
>>>> 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).
>
> It's not just basic software engineering, because most languages  
> can't be
> moved closer to the problem domain.  It's likely you like
> Lisp/Ruby/Smalltalk exactly because they can be, but that's why  
> they're
> special.  They can be used to build DSL's.
>
> When I program in Csharp, VB, or Java, I find myself writing a lot  
> of loops,
> many of them looking very similar, because these languages offer me  
> no clean
> way to stop writing the same loops over and over.  Yet in Lisp,  
> Smalltalk,
> or Ruby, you do something a few times, get tired of doing it,  
> extend the
> language with a new operator, and program with it.
>
> If I add a bunch of stuff that makes the language really good at  
> generating
> html, say a macro...
>
> (html (:html
>     (:head (:title "My Document"))
>     (:body (:h1 "My Document")
>         (:prin1 (get-universal-time)))))
>
> Or abuse blocks for the same purpose...
>
> SomeObject>>renderContentOn: html
>     html
>         head: [html title:'My Document'];
>         body: [html heading: 'My Document';
>                     text: DateAndTime now]

We may have to agree to disagree. I just don't see this. Or at least,  
I don't see it the same way. The code snippets above are (to my eye)  
still Lisp and Smalltalk respectively.

It is possible to move any language closer to the domain. Admittedly,  
it is easier in some languages than in others. But, moving the  
language closer to the domain is still (to my eye) a basic part of  
software engineering, regardless of the language. It's just a matter  
of degrees.

Take C. There are two reasons we might define a function in C. First,  
we might want to capture and generalize a bit of code so that we can  
reuse it. Second, we might want to capture and label a bit of code to  
make reading the source code easier (even if we only use the function  
once). These are not mutually exclusive. The intersection  
(generalizing a bit of code for reuse AND to make the source easier  
to read) seems to be firmly in the realm of bottom-up programming.

Here's a Java html example (imagine your page is a subclass of an  
html class--you override content() to set the page's content.)

public void content(){

	header( title("My Document));

	body(
		heading("My Document),
		text( currentDateAndTime())
	);
}

This seems as good as the Lisp/Smalltalk examples. Admittedly a C  
implementation would be much messier (we're limited to functions,  
structs, global variables and macros), but it still could be done.

html();

	header();
		title("My Document");
	closeHeader();

	body();
		heading("My Document");
		text(currentDateAndTime();
	closeBody();

closeHtml();


Hmm. That's actually not too bad.

Admittedly, there are very few well written libraries for Java/C/etc.  
But that doesn't mean it can't (or shouldn't) be done.

-Rich-