DSLs As Rails Plugins 1
Thanks to everybody who attended my talk on DSL's yesterday at RailsConf. I had a lot of positive feedback and I thoroughly enjoyed giving it. A couple of great points came up in the Q&A session, that I will be addressing here over the next few of days.
Determining when you need a full fledged DSL vs. a library of classes and methods. In particular one person pointed out that deck.shuffle in my example was probably fine.
Is there (or should there be) a distinction between XML, or other mark-up, based DSLs and executable DSLs like the ones I was discussing.
I've posted the slides for my talk here. If you have feedback, positive or negative, on the talk or ideas on the above questions, please comment below!
Steve
New Talk Abstract
I've updated the abstract for my RailsConf talk. There's a talk immediately after mine that is going to focus on the details of implementing a Domain Specific Language in Ruby. Therefore, I'm going to talk at a little higher level about designing and using a DSL. Leave me some feedback if you have thoughts on this.
Domain Specific Languages as Rails Plugins
“Reuse is Vastly Overrated”—DHH 1/21/2006.
Reuse of business logic between applications is difficult. By definition business logic is what distinguishes one business from another and one application from another. However, DSL’s might provide a reusable context to describe business rules within a domain. The DSL provides a middle ground between impractical or constraining reuse and laborious coding from scratch.
In this talk we will look at the usage of some common Rails DSLs and the design of a new DSL for managing randomness in hobby/adventure game apps. We will end with some discussion of packing DSLs as plugins, pitfalls of DSLs and common domains in Rails that need DSL plugins.
Steve
