On Sep 1, 2006, at 1:09 PM, Ramon Leon wrote:

> I'm headed out the door, so I'll respond to the rest later, but..
>
>> 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.
>
> While I'd consider this an embedded DSL, it's certainly not as  
> good, because
> the question arises what can go in a body?   How many args does  
> body take,
> nesting function calls like that won't be able to represent the same
> hierarchical structure that html can represent, Lisp and Smalltalk  
> can get
> around this with anonymous functions, I'm not sure this can.

As an example, Body can take a variable number of Tag objects. Java  
methods can be defined to accept variable numbers of parameters, so  
this isn't a problem. Tag objects can also be nested inside other  
tags (allowing us to express complete html hierarchies).  
Alternatively, all tags (including body) could accept any objects-- 
and internally it calls toString() on the object. This would let you  
pass in a mixture of Tag objects and literal strings.

Given that, I don't see any difference between my nested calls in  
Java and your nested calls in Smalltalk.

While I fully admit that it's easier and cleaner to do bottom-up  
programming in dynamic languages, it is still possible (to some  
degree) to use these techniques in any language.

Any time you create a function, class or whatever, you are bringing  
the language closer to the problem domain. There's no distinguishable  
line between bottom-up programming and simply creating well- 
engineered classes and functions. Anyone can look at both ends of the  
spectrum and see that they look different--but that ignores how  
quickly things blur in the middle.

On the other hand, there is a sharp line between interpreted DSLs and  
regular programming. That's one of the reasons I prefer to use the  
term DSL strictly for interpreted DSLs. The term (when used that way)  
has a clear meaning.

-Rich-