What separates a Ruby DSL from an ordinary API

Question

What are some defining characteristics of a Ruby DSL that separate it from just a regular API?

oreillynet.com/onlamp/blog/2007/05/… – Miles Oct 19 '09 at 9:47

Adam Byrtek · Accepted Answer · 2009-10-19 09:52:19Z

When you use an API you instantiate objects and call methods in an imperative manner. On the other hand a good DSL should be declarative, representing rules and relationships in your problem domain, not instructions to be executed. Moreover ideally DSL should be readable and modifiable by somebody who is not a programmer (which is not the case with APIs).

Also please keep in mind the distinction between internal and external DSLs.

Internal domain specific language is embedded in a programming language (eg. Ruby). It's easy to implement, but the structure of the DSL is dependent on the parent language it is embedded in.
External domain specific language is a separate language designed with the particular domain in mind. It gives you a greater flexibility when it comes to syntax, but you have to implement the code to interpret it. It's also more secure, as the person editing domain rules doesn't have access to all the power of the parent language.

+1 for making the distinction between internal and external DSLs. — ctford, Oct 19 '09 at 11:52

Ira Baxter · Answer 2 · 2009-10-13 00:00:58Z

up vote4down vote

DSL (domain specific language) is an over-hyped term. If you are simply using a sub-set of a language (say Ruby), how is it a different language than the original? The answer is, it isn't.

However, if you do some preprocessing of the source text to introduce new syntax or new semantics not found in the core language then you indeed have a new language, which may be domain-specific.

edited Oct 13 '09 at 0:00

Ira Baxter
43.8k659117

answered Oct 12 '09 at 23:53

cdiggins
5,0652339

So if I override the << operator to do something other than what it would normally do on a plain object in Ruby, is that "new syntax"? Or is it only new syntax if it's never been seen in any language before? – Chuck Oct 13 '09 at 1:56

Well I don't think that syntax has to be completely novel to satisfy the requirements for a new DSL. I have to admit that there is no consensus whether simply overloading operators is sufficient to create a DSL especially when you are stuck with existing precedence rules, and other issues (e.g. the short-circuit evaluation semantics of || and && in C++). – cdiggins Oct 13 '09 at 13:42

Totally agree on this. The trouble is that you find many people that are absolutely sure they have a solid definition of what makes a DSL, but none of them agree! In practice things are just more or less DSL-y, with languages like Ruby and Lisp encouraging the style, and languages like Java making it damn near impossible.– gtd Oct 16 '09 at 18:28

The term "DSL" is vastly abused within the Ruby context. Ruby's syntax is very flexible, so it allows one to write APIs that superficially vaguely resemble English sentences. This is commonly and inappropriately termed a "DSL," but this is not a DSL in the strict technical sense, it's just a set of cleverly named methods and variables written in ordinary Ruby. There is no new syntax, so a new "language" is not being developed. A true DSL requires the ability to create syntactic rules, such as by using a parser generator or Lisp macros. – Paul Legato May 30 '10 at 8:30

add comment

DigitalRoss · Answer 3 · 2009-10-13 00:01:04Z

The combination of Ruby's poetry mode and operator overloading does present the possibility of having something that is at the same time legal Ruby syntax and a reasonable DSL.

And the continued aggravation that is XML does show that perhaps the simple DSL built into all those config files wasn't completely misguided..

Sarah Mei · Answer 4 · 2009-10-13 01:53:12Z

Creating a DSL:

Adding new methods to the Object class so that you can just call them as if they were built-in language constructs. (see rake)
Creating methods on a custom object or set of objects, and then having script files run the statements in the context of a top-level object. (see capistrano)

API design:

Creating methods on a custom object or set of objects, so the user creates an object to use the methods.
Creating methods as class methods, so that the user prefixes the classname in front of all the methods.
Creating methods as a mixin that users include or extend to use the methods in their custom objects.

So yes, the line is thin between them. It's trivial to turn a custom set of objects into a DSL by adding one method that runs a script file in the right context.

Lolindrath · Answer 5 · 2009-10-19 11:48:27Z

The difference between a DSL and an API to me is that a DSL could be at least understood (and verified) if not written as a sub-language of Ruby by someone in that domain.

For example, you could have financial analysts writing rules for a stock trading application in a Ruby DSL and they would never have to know they were using Ruby.

edebill · Answer 6 · 2009-10-19 16:21:15Z

They are, in fact, the same thing. DSLs are generally implemented via the normal language mechanisms in Ruby, so technically they're all APIs.

However, for people to recognize something as a DSL, it usually ends up adding what look like declarative statements to existing classes. Something like the validators and relationship declarations in ActiveRecord.

class Foo << ActiveRecord::Base
  validates_uniqueness_of :name
  validates_numericality_of :number, :integer_only => true

end

looks like a DSL, while the following doesn't:

class Foo <<ActiveRecord::BAse
  def validate
    unless unique? name
      errors.add(:name, "must be unique")
    end

    unless number.to_s.match?(/^[-]?\d$/)
      errors.add(:number, "must be an integer")
    end
  end
end

They're both going to be implemented by normal Ruby code. It's just that one looks like you've got cool new language constructs, while the other seems rather pedestrian (and overly verbose, etc. etc.)

Kumar's Blog

Sunday, January 5, 2014

What separates a Ruby DSL from an ordinary API

6 Answers

No comments: