SPA2005 session: Embedded Domain-Specific Languages | |||
| One-line description: | How can we write explicit and usable domain-specific languages within conventional programming environments | ||
| Session format: | Think tank [read about the different session types] | ||
| Abstract: | Paraphrasing Philip Greenspun, every significant program contains an ad-hoc informally-specified bug-ridden slow implementation of one or more domain-specific languages. While this is known in the dynamic language community (as Dick Gabriel pointed out during his keynote, lispers first write a language then use that to write the application), it's much less recognised in the static language communities where most of us work. We believe that implicit domain-specific languages should be made explicit as part of the development process so that they can be clarified and made easier to use. Often this has to be done within the programming language of the application, rather than as a separate language. The relevant techniques should be part of the arsenal of every mature software professional. This session will explore how to design and implement domain-specific languages within conventional languages such as Java and C#. In particular, we are interested in designing within the underlying language's features, such as its type system, rather than hosting a different language like Jython or Groovy. As an example, we will use the jMock library, for which we have developed a "builder" language to express constraints on an object under test. Our experience with this API is that it has generated strong reactions for and against. We are interested in exploring what is behind the negative reactions beyond our unusual API style. | ||
| Audience background: | Architects, designers, and experienced developers who are interested in language and API usability. | ||
| Benefits of participating: | The participants will be able to consider language and design issues that are often left implicit during system development with a group of like-minded professionals. | ||
| Materials provided: | Introductory poster - problem statement - jMock example | ||
| Process: | 00 Introductions and problem statement 05 Very brief demo of jMock as an example, discussing motivations and trade-offs 15 Brainstorm and write skeletons for candidate patterns 65 Wrap-up and summary | ||
| Outputs: | Summary poster | ||
| History: | First time. Might try a BOF at OOPLSA | ||
| Presenters | |||
| 1. Nat Pryce B13media Ltd. |
2. Steve Freeman Thoughtworks |
3. | |