This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

QCon SF 2009: Brian Guthrie, Internal DSLs in Groovy, Ruby, and Others

Stefan Tilkov,

These are my unedited notes from Brian Guthrie's talk about Internal DSLs in Groovy, Ruby, and Others

  • A DSL is a computer programming language of limited expressiveness focused on a particular domain
  • PHP originally started out as a DSL, but is no more
  • SQL is an excellent example of a DSL
  • Ant as an example of focus on a particular domain
  • 2 flavors of DSLs internal and external
  • An internal DSL is a kind of API
  • Expressiveness matters more than the implementation details
  • methods in a DSL make little sense out of context
  • Example: fluid interface as DSL, calendar.add("dentist").from(fourPM).to(fivePM).at("123 N Southwest Ave");
  • Example of something that hides intent in lots of ceremony
  • be declarative, be accepting
  • every API is a conversation - with yourself, your team members, your business
  • Patterns for internal DSLs
  • method chaining | type transmogrification
  • Explanation of fluid interface pattern using the Calendar example
  • Example: Mocha, Ruby mocking framework as another example
  • the finishing problem: what's the final thing that gets returned?
  • nested closures | semantic model
  • a lot of times, a DSL is an interface to a library, but there should be an underlying model

  • Awsymandias: DSL to describe Amazon EC2 environments

    stack = define ... do |s| s.instance :db, :instance_type => "m1.large" end stack.launch

  • (classical model of using ruby class methods and blocks)

  • definition should != domain model
  • high-level DSL should be separate from the domain model [I very much agree; much of it is due to the tricks you have to do to get something that reads nicely]
  • keep domain model clean
  • literal extension | string polishing
  • monkey patching and converting something that's nearly code to actual code
  • Groovy example of a simple DSL, similar to what you'd do with Hpricot
  • digression: shows how to re-open classes in Ruby, using things like 5.seconds
  • shotgun approach to opening classes
  • Groovy's category support enables clean addition of methods to classes
  • [Didn't know Groovy has some kind of extension method support, pretty neat]
  • literal extension | method chaining
  • Example: jQuery uses Javascripts prototype model to add functions to objects as needed to support fluid method chains
  • method chaining andChaining andChaining
  • example: Ioke
  • DSL for Starbuck's weird combinations
  • ispec is the coolest spec framework ever
  • a DSL is an API, a language, a conversation
  • be declarative
  • know your audience
  • use fluent interfaces, message chains
  • nested function | closure
  • audience comment: Showing a complex API that's simplified misses the point, which is about having domain experts understand the language [I disagree, the domain expert in this example might be someone who understands the simplified code, but not the convoluted mess it's become]
  • Martin Fowler: both DSLs for programmers and non-programmers are useful
  • Q. Another useful pattern: natural language interpretation, Cucumber as an example
  • Q. Real world use? A. Often used in high-level functional test specs