items.filter(:price + 100 < 200).sql
  #=> "SELECT * FROM items WHERE ((price + 100) < 200)"

items.filter((:price + 100 < 200) & (:price * 100 <= 200)).sql
  #=> "SELECT * FROM items WHERE (((price + 100) < 200) AND ((price * 100) < = 200))"

Furthermore, I think you need to discern between internal and external DSLs (as per http://www.martinfowler.com/bliki/DomainSpecificLanguage.html). I’m guessing doing external DSLs is just as hard in both languages. You may argue you like internal DSLs in LISP better, but in my book, internals DSLs in Ruby are much more readable and human friendly (admitted, Datamapper may not be the best example).

@Andreas: I only mean to deal with internal DSLs here. And maybe I am arguing from example, but the definition I propose is basically this: an internal DSL, as distinct from an API, introduces new syntax to express a solution naturally in the language of the problem domain. An API might also use method and class (or property and procedure) names from the problem domain, and it should, but unless it defines new syntax, it’s not a DSL.

And again, I don’t advocate DSLs over well-designed APIs, or vice versa. Nor do I advocate Lisp over Ruby on these grounds. I just want us to be clear on definitions.

in your post, you write: “exhibitions and run-time wouldn’t be variables”. So what if you need to store the table’s name in a variable? How would your DSL look like in this case? My Lisp is a bit rusty

(let table-name "exhibitions"
  ; ...
  )
; or just...
(define table-name "exhibitions")

[dialect: Scheme]

Javascript doesn’t read like English, and somehow, I don’t have any trouble being productive there.

But you’re going about this all wrong.

“It’s still not a DSL under my definition, because it doesn’t actually introduce syntax.”

The problem isn’t DSL here. The problem is you can’t arbitrarily redefine software engineering terms to mean what you think they should.

I think cars should have six wheels. Therefore vehicles without six wheels aren’t cars.

It doesn’t work like that.

Finders have been claimed to be a DSL in ActiveRecord that this shouldn’t be up for question.

The problem with :conditions isn’t that it’s a String. It’s that it’s a leaky abstraction. It subverts the entire point of an O/R Mapper in the first place. Leaky abstractions are not good things. This leak is most convenient in scenarios with complex queries, but then again, it’s the same scenario where it falls down most.

DataMapper “supports” the same leak. It’s not because it’s a great feature. It’s because robust abstractions for query mechanisms are *hard*. Especially so if you’re fixated on avoiding the more traditional Query mechanisms found in libraries like Hibernate.

I agree, I’m not a big fan of the Symbol Operators these days. It’s a struggle to find a balance between robust APIs and something people will actually use.

I’m feeling rather disenfranchised with the whole “beauty” ideal these days. None of the Ruby O/RMs are especially beautiful. Compromises have to be made.

BTW, a DSL may be your only API. Or it could be just one of your interfaces making up your API. The two are not synonymous. You can have an API without a DSL.

Anyways, Internal/External DSLs… not terms redefine-able at will.

The problem is you can’t arbitrarily redefine software engineering terms to mean what you think they should.

Well, for one thing, I’m not the only one who has come to this definition: see the comments here (also linked in the original post). Think about it: for it to be a domain-specific language, it has to be a discernibly different language within the host language, not just a special vocabulary.

Secondly, the term was sufficiently ill-defined before it was adopted by Rubyists—and since then the waters have been muddied much further by people bandying the term about without really understanding it. A lot of Ruby interfaces are written in a DSLish style, and that’s fine, but calling these things DSLs doesn’t make them such.

Thirdly, sure I can ;p That is, if a term is thrown around without sufficient definition to advance conversation in the industry, I actually have a responsibility to define the term as I use it, and as I see it best defined. Creating (or co-opting) new jargon without need and without a solid definition doesn’t help us move the state of the art forward.