WebDSL: Lessons Learned from Creating a DSL
He just finished writing a paper about "WebDSL: A Case Study in Domain-Specific Language Engineering" which looks back at the design and implementation of this particular DSL.
the paper has two introductory sections about the 'domain-specific language engineering' process and three discussion sections evaluating WebDSL as a web engineering solution, discussing related DSL engineering approaches, and research challenges for language engineering
WebDSL is domain-specific language for developing dynamic web applications with a rich data model. The underlying target architecture is based on JBoss's Seam. He published the first alpha release of WebDSL in December 2007.
Eelco defines a DSL as:
- A DSL is a language, that is, a collection of sentences in a textual or visual notation with a formally defined syntax and semantics
- A DSL is high-level in the sense that it abstracts from low-level implementation details, and possibly from particularities of the implementation platform.
- A DSL should support software implementation.
- The concepts and abstractions of a DSL are related to a particular domain.
Eelco sees that the goal of DSLs is to:
...increase the productivity of software engineers by abstracting from low-level boilerplate code.
Conventional abstraction mechanisms of general purpose programming languages such as methods and classes, are no longer sufficient for creating new abstraction layers. While libraries and frameworks are good at encapsulating functionality, the language which developers need to use to reach that functionality, i.e. the application programmers interface (API), is often awkward.
In some cases, an API provides support for a more appropriate language, but then utterances take the form of string literals that are passed to library calls (e.g. SQL queries) and which are not checked syntactically, let alone semantically, by the host language.
He argues that we need:
...technology for designing and implementing DSLs, but also a methodology for using that technology. That is, a collection of guidelines, design patterns, and reusable DSL components that show developers how to tackle common language design and implementation issues.
Even though, he notes,
The engineering of web applications is a fairly mature field.... there is a strong case for the development of a DSL for this domain;
- Task Automation: Despite [Java Servlets and JSF], web programming often requires a substantial amount of boilerplate code;
- Notation:The current platform provides an amalgam of often verbose languages addressing different concerns, which are not integrated.
- Verification: Another consequence of the lack of integration of web application technologies is the lack of static verification of implementations
- GUI Construction: [JSP-style frameworks have often] no knowledge of the structure of the HTML code generated by the template, so it is very easy to generate non well-formed documents. [Even in the case of JSF] templates are very verbose and concerned with low-level details.
- Analysis and Optimization: For example, optimization of database queries in the style of Wiedermann and Cook  might be useful in improving the performance of applications without resorting to manual tuning of generated queries.
Eelco identifies 3 DSL design patterns;
- finding programming patterns,
- designing a core language,
- building syntactic abstractions on top of the core language.
For WebDSL he starts by defining a textual Data Model DSL. The code generator is transforming entity definition in JPA-based Java code. He then develops a View/Edit DSL from which he generates JSF pages and Seam session beans. From this point, WebDSL can be extended to "increase coverage" by introducing customizable View/Edit pages, collections and complex associations.
Eelco reports ratios of lines of code generated over lines of DSL of over 100 which he sees as an opportunity to improve the generator.
The article continues with discussions on Language Engineering Paradigms and Language Engineering Challenges and in particular "Model Migration".
Based on his experience, he recommends:
- [Start developing] a DSL ... when there is a good understanding of the application domain and there exists a considerable code base for systems in the domain.
- Start with considering relatively large chunks of programs as candidate patterns.
- Study and understand the technology and recognize common patterns. Set up a basic generator early on
- Do not overspecialize syntax.
- Do not try to identify a core language from the start. The result may be too close to the target target technology.
- Extend the core language with syntactic abstractions that allow concise expression.
- Include facilities to build a library, such as modules for organization of the code base and parametric abstraction over DSL fragments
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015