Wow, Ralph Johnson mentioned this thread on his blog (http:// 
www.cincomsmalltalk.com/userblogs/ralph/blogView? 
showComments=true&entry=3334257004).

Seems a bit odd, being called "The Ruby guy". Sure, I use Ruby.  
Sometimes. I also use lisp, smalltalk, objective c, java and (when  
forced) c++. Of them, Ruby and Smalltalk are probably my current  
favorites (unless I'm doing a GUI application for the Mac, then  
Objective C is probably the top). Unfortunately, I'm usually forced  
to work in Java, lots and lots of Java. If anything, I'm an unwilling  
Java guy.

Ralph also seems to have misunderstood what I was trying to say. I  
don't want to start a fight or anything, but I thought others might  
also have missed my point (or the larger point might have gotten lost  
when I started answering specific questions). I'd like to clear  
things up, since I think DSLs can be a very useful tool, and are well  
worth learning. I hope others might find them useful.

"...it took a little work to figure out what he meant. Part of the  
problem was that Smalltalkers make DSLs of a certain type so  
effortlessly that they just call it "programming"."

Part of the problem is different people seem to have different  
interpretations of what a DSL is. In some definitions, any  
significantly complicated project becomes a DSL (or at least any well- 
written project). After all, we create functions, methods, objects,  
etc. that clearly and simply express the domain. In this sense,  
programming Smalltalk is very much like writing a DSL (though I think  
the trend is even more pronounced in Lisp). However, I don't think  
this definition is particularly useful.

When I spoke about DSLs, I was particularly talking about reading in  
and evaluating text files. The simplest example is a configuration  
file. Several of the online examples also follow this guideline.  
Admittedly, this is more useful for languages like Java (and,  
ironically much more difficult to create), since it lets you change  
an applications behavior without recompiling. There are still some  
clear benefits for Ruby and Smalltalk. Rails, for example, makes  
great use of DSLs.

You could argue that, for Smalltalk, the idea of a DSL is a bit  
strange, since it involves moving some of the code outside the image.  
Especially in Squeak, since (as far as I know) you have to leave the  
squeak environment to edit arbitrary text files.

"The Ruby guy wanted a little more, he wanted a certain syntax."

I'm not entirely sure what this means. I think he means I wanted a  
specific, non-smalltalk syntax. That's not really true. I'll probably  
implement my DSL using a pure smalltalk syntax (or smalltalk with  
minimal text processing). It's close enough for me. However, someone  
did ask what my ideal syntax would be--and so the thread went off on  
that tangent.

In general, yes. The advice to utilize Smalltalk syntax directly is  
good. That is what I had planned to do from the start. Originally I  
was trying to find examples of how others had used Smalltalk syntax  
to do this sort of parsing. I was hoping to learn a few tricks and  
tips by looking at other implementations.

"However, creating good languages is not easy, and few people can do  
it. I think that is the limiting factor in DSLs."

This is definitely true if you're trying to create a Turing Complete  
language for general programming. However, most DSLs are not Turing  
Complete. They are small, focused, little things. They do one thing,  
and they do it as simply and cleanly as possible. As a result, they  
are not typically very hard to write.

Here's an example of what I'm talking about. I'm about to implement a  
neural net. I'll be experimenting with many different sizes and  
topographies. This is an excellent opportunity for a DSL. I could  
create several net-building scripts that are then loaded and  
interpreted by the main application. Then, if someone wanted a  
different topography, they could just write and load their own build  
script. I could even build an object to automatically write out build  
script permutations. The scripts themselves act as both source code  
and log.

-Rich-