Here’s what he says, abridged:
(when (and (< time 20:00)
(trade (make-shares 100 x)))
IMO, that’s not a DSL – that’s just a set of function calls in an existing language.
Craig answered back (a section, possibly completely taken out of context):
A set of function calls in an existing language is generally preferable to a completely separate language. Particularly if it’s the language that you’re using to write the rest of your system.
While the concept of domain specific languages is different things to different people, I fundamentally think that the “Little Languages” (Jon Bentley, Little languages, Communications of the ACM, 29(8):711–21, August 1986.) philsophy applies. As far as I am concerned that means the languages should be simple enough to write by hand and clear enough that non-technical stakeholders can understand them. Why? Because for my money, a DSL is useful when it can help you ensure that the intent of a system is the same as the code that runs a system. And you cannot be sure of intent unless someone can assert the rules are correct.
I am sure I am missing some of the point of DSLs and feel free to educate/flame me, but for me the gain of building a DSL (even a very simple one) is that it can be validated against requirements much easier than typical code. In fact, it should be editable by stakeholders as well (perhaps not all stakeholders, but some).
If your DSLs are all based on language semantics (e.g. internal versus external DSLs I think its referred to by Fowler) then it makes them only readable to developers. Sounds like the use-case was for a rules-engine not a DSL.