[timruffles]

I think it needs a foreword: "your problem likely is nowhere near needing a DSL, please don't write one just because it makes you look clever".

Signed: everyone who's ever used a DSL which could have been written better as a couple of dozen functions.

[saturnflyer]

I'm the author. In fact, the first bit of advice I have in the book is: Don't. DSLs often involve metaprogramming, but they don't have to. I'm writing it to record the code practices that I have found useful in getting things right and gather advice and tips from others who have done the same. DSLs are always about communication, so my goal is to create a book that helps developers communicate the purpose of the aspects of their project through code.

[grandpa]

Spoiler: the second bit of advice is "Step 2: No, seriously. Don't"

[tel]

Almost any problem can be meaningfully and usefully solved by introduction of a DSL. It's a remarkably flexible technique.

Ruby is a really bad language to write good DSLs in. Metaprogramming is an awkward replacement for better DSL facilities.

Maybe this book can demonstrate better techniques?

[ritchiea]

Interesting, that runs counter to the prevailing sentiment that Ruby's metaprogramming makes it great for writing DSLs. What language features do you prefer for writing DSLs?

[tel]

Typing, phantom typing, straightforward lambdas, sum types, tail-recursion, direct syntax abstractions (both Lisp and Idris are great examples).

I find that metaprogramming in Ruby is a tremendous hack for getting something like syntax abstraction and something like control over evaluation order. Personally, syntax abstraction doesn't feel super important for deep or shallow embedded DSLs (though it's obvious a big deal in external DSLs if you want to walk that minefield). You need more than nothing, but making it "human language like" is ridiculous.

Controlling flow is a big part of it though. Ruby's block syntax does a lot here, but frankly functions/abstractions never feel first class in Ruby---only Objects do and Objects are too heavyweight.

[mattgreenrocks]

Isn't the DSL just an ad-hoc implementation of a rules engine in many cases?

[tel]

Can be. I see a lot of those, but rules engines are far from the only denotation of a DSL. It just tends to be that people want DSLs to be sort of natural language which drives people to end up with something like predicate logic which drives people to end up with something like Prolog and then you might as well have a rules engine.

[dkarapetyan]

What would those be?

[vinceguidry]

I should someday make a screencast showing how I use DSLs in my projects. I've done the "couple dozen functions" thing enough times to know it only goes so far, whenever I find myself reaching for a DSL, I'd wished I'd done it sooner.

DSLs should be looked at as syntactic sugar for object instantiation. Language methods should set the object's state or run an instance method. Object behavior goes in the object's class.

I'm looking at one of my DSLs, it's a module with a parse method that takes a file with a default argument to the common "XXXXfile" that I see used a lot for DSLs. It opens the file and module_eval's the code. I use instance and module variables to hold state in the execution context of the DSL.

If you stick to this pattern you'll find a DSL easy to manage. I use it as a replacement for instantiating objects with YAML files, which I find brittle. I hate maintaining those, but a DSL will give me just the right amount of indirection. I can express the objects exactly how I want them to be expressed, which is a big win for me.

[jes5199]

how about: every DSL should be a thin translation layer over a clean API. Too many times I've been burned by gems that provide a DSL and there's no other way to use their functionality.

[saturnflyer]

Yes. Too often this is done even with complex procedures inside methods. A good DSL should be syntactic sugar for making things easy or at least provide some syntactic vinegar for doing non-recommended things (while still allowing them).

[thibaut_barrere]

That you suffered from DSL is probably a sign that this book will be filling a gap :-)

I had /some/ bad experiences with some DSL, but most of my experiences with them were pretty good (even those who I didn't write).

[jfaucett]

"most of my experiences with them were pretty good (even those who I didn't write)." - lol, gotta love programmer arrogance, I'm guilty as well.

I can't remember the joke but the tagline goes, "Code I didn't write" anyone?

[thibaut_barrere]

Arrogance here is more caused by my bad english :-) I use more DSL that other people wrote, than mine.