John Slaby – Why I have come to prefer fluent interfaces over other kinds of DSLs

John Slaby works for Raytheon, a large defense contractor, where he has tried over two dozen full-featured DSLs to support users within the company. But the teams using them have been dissolved and the value of the DSLs was somehow lost. And when new features needed to be added, this was done by different teams that did not understand the DSLs. So they ask “what is this, do we still need it?”

Why? DSLs need: specialized tooling, additional licensing, additional skills and maintenance not directly related to the product.

This has resulted at the fact that Raytheon in largely unable to remain using DSLs later in development projects.

John argues that fluent interfaces are the perfect middle ground between DSLs and custom code. Not just because no special tools or skills are needed, but also because they are testable and can be managed in the same way as the code base.

He presents an example: a baseball app. For the non-US audience, he elaborates on some of the crazy baseball rules. One of the reason for using fluent interfaces was the troubles of testing. Explained in one screen:2014-04-09 11.30.24

In addition to unit testing, fluent interfaces also ease integration testing, as it is easy to express real life scenario’s. In the baseball case, John tested his scores against an open data set with scores:

20140409_113602

In summary, John states that he loves fluent interfaces, because they are a great way to get organizations comfortable with domain specific languages.

 

3 Comments

  1. Marcel Weiher

    So maybe these Smalltalk folks knew something after all back in the 70ies: methods read like sentences and self is the default return value if nothing else is specified; the semicolon is used for message chaining even if the result isn’t self.

    GameState new
    teamIsUp;
    runnerOnFirst;
    runnerOnSecond;
    balls:3;
    strikes:2;
    setup.

  2. Torsten

    You can even have instance creation methods with own custom keyword selectors:

    GameArea width: 10 height: 20

    and even model units with simple messages:

    PDFDocument width: 1000 mm

    A pleasure to read and Smalltalk is always easy to extend. For instance to provide access to complex numbers one adds a message #i to Number:

    i
    ^ Complex real: 0 imaginary: self

    With this one can now write:

    0.5 + 2 i

    Yes – Smalltalk is still the best to provide DSL’s together with the implementation language – as all of it is similar to natural english and very easy read and to extend.

    What people (outside the regular ST community) never really understood is that a Smalltalk system itself is not only language – it is a language on top of a dynamic object system where anything can be modeled/implemented using objects and messages.

    Try yourself: http://www.pharo.org

  3. Egbert Teeselink

    Nice summary! Slaby seems to be one of the few people who’ve really taken MDSD-ish approaches all the way, into the industry, into real life, found out what works and what doesn’t, and then shared all that knowledge.

    I’m not sure whether it makes me happy or sad that what he found, in the end, was that DSLs, SchmeSLs – as long as it’s real code and it looks like JQuery calls.

Comments are closed.