I think in those contexts, DSL is more a description of how an API feels to use, than a precise technical categorisation.`
Ergonomic distinctions are useful though, as is the distinction between declarative-style APIs and more imperative ones, which 'DSL' is often used to make.
Those are just the "english-y" DSLs. Not all are attempting to read like english. And even for those that are, the point isn't to be writing in english, the point is to be at least halfway readable to a non-programmer reading over your shoulder.
Okay, but it's not really all that clear that "sum.should == 3" is actually any more readable than "assert(sum == 3)". (Do you really have non-programmers reading code over your shoulder? I can't think of any case in a 10+ year career where that's happened.)
> ... the point is to be at least halfway readable to a non-programmer reading over your shoulder.
That's the same argument for filing the serial number off of TDD and calling it BDD: sometime, somewhere, somehow eventually some non-programmer is going to have to maintain source code without a trained professional programmer around to help.
I don't get it; FIT's been around much, much longer. What kind of non-developer business rule expert can read the punctuation-sprinkled pseudo-English pidgin Ruby spreads around but doesn't know how to manipulate tabular data in a spreadsheet?
The BDD reference is not just an analogy, it's what these are for. And it's not about non-programmers maintaining the code. Not at all. It's about a business owner and a programmer sitting together and making executable specs together.
I don't really get it, but I'm curious. People I respect swear by it.
Really? That's the example you want to use. First thing I see on that page:
get / 'orders' >> :orders > :index
with route / :slug / 'order' >> :orders do
get > :show
put > :update
end
get {'item_images' => :controller} / :image > :show
That looks like Ruby all over the place. Yeah, it overloads operator methods more than most Ruby code, but it's very clear that it's Ruby.
Ergonomic distinctions are useful though, as is the distinction between declarative-style APIs and more imperative ones, which 'DSL' is often used to make.