Thursday, April 26, 2007

DSL: Expressive Software

Lately I've been thinking about DSLs that are designed for and by programmers. After some recent work and discussions I formed the following idea.

Expressive Software is a style of software development inspired by Domain Specific Languages. In-fact, Expressive Software can be considered a type of Domain Specific Language. Specifically, Domain Specific Languages designed for programmers can be categorized as Expressive Software.

The term Domain Specific Language is overloaded and suffers from lack of clarity*. Because of the lack of clarity some consider Rails to be a Domain Specific Language and others are vehemently against the idea. However, it's hard to argue against Rails being considered expressive software.

The expressiveness of Rails can be seen in it's many class methods. A good example of a class method designed to be expressive is the has_many method of ActiveRecord::Base. The has_many method and all the other expressive methods of Rails make working with it easy when developing new and maintaining old code.

An example of creating your own Expressive Software could be a class that defines a workflow path. The class could do this via the following syntax:
class StandardPath
pages :select_product, :contact_information, :summary

path select_product >> contact_information >> summary
The same application may have a path for existing users
class ExistingUserPath < StandardPath
path select_product >> summary
The above example utilizes an expressive class method, similar to Rails. In addition it also shows an example of using a Fluent Interface (the path method). Utilizing a Fluent Interface helps create software that expresses intent within the code. This is one of the goals of Expressive Software, to easily convey the intent within the code itself.

Software designed with an Expressive Software mentality is easier to read and maintain. This style of software development can lead to productivity gains. While it's hard to quantify the level of productivity gains, Rails (and various other examples such as Rake and Builder) prove that a higher level of productivity can and should be achieved.

* This isn't the first time I've mentioned that I believe "DSL" is too vague. In the Business Natural Language material I've also discussed why I think there's a need to create more descriptive phrases for more focused ideas.


  1. "suffer from lack of clarity*"

    Ha. Nice example. I looked for the matching asterisk as a footnote but couldn't get clarity on what it was to mean! :D

  2. Anonymous10:42 AM

    Hah, thanks for pointing that out. It's been updated.


  3. It is really unfortunate: the term "DSL" is finally getting some traction in the mainstream and the industry, and just as this happens, the community comes up with new terms.

    I think this is not helpful.

  4. Anonymous12:26 PM


    Some people, who are much smarter than I am, agree with you. Conversely, other people who are also smarter than I am, believe that better terms are essential.

    I've chosen to write about my experiences. In my experiences I've found it inefficient to discuss a term as generic as SOA or DSL. If that isn't your experience then I don't see any reason for you not to use the term DSL.

    Let's hope you are right in the end. I would prefer less phrases as long as I can still have constructive conversations.

  5. This concept is not new. If you read Small talk Design Patterns, it is called as "Intention Revealing Selector".

  6. Anonymous4:32 PM

    Very cool, I have the book, but never got through it. I'll go back and make sure I check out that secion. Thanks for the note.


Note: Only a member of this blog may post a comment.