A Comparative Case Study of Code Reuse With Language Oriented Programming

There is a gap between our ability to reuse high-level concepts in software design and our ability to reuse the code implementing them. Language Oriented Programming (LOP) is a software development paradigm that aims to close this gap, through extensive use of Domain Specific Languages (DSLs). With LOP, the high-level reusable concepts become reusable DSL constructs, and their translation into code level concepts is done in the DSL implementation. Particular products are implemented using DSL code, thus reusing only high-level concepts. In this paper we provide a comparison between two implementation approaches for LOP: (a) using external DSLs with a projectional language workbench (MPS); and (b) using internal DSLs with an LOP language (Cedalion). To demonstrate how reuse is achieved in each approach, we present a small case study, where LOP is used to build a Software Product Line (SPL) of calculator software.

💡 Research Summary

The paper investigates how Language Oriented Programming (LOP) can bridge the gap between high‑level design concepts and low‑level implementation code by means of Domain‑Specific Languages (DSLs). The authors compare two concrete LOP approaches: (a) external DSLs built with the projectional language workbench JetBrains MPS, and (b) internal DSLs built with the LOP language Cedalion, which is based on logic programming. Both approaches are exercised on the same case study – a small Software Product Line (SPL) of calculators – allowing a side‑by‑side assessment of reuse, development effort, and maintainability.

The motivation section explains that traditional reuse often fails because reusable design knowledge (e.g., a state‑machine pattern) becomes tangled with product‑specific details when developers manually “compile” the concept into code. DSLs solve this by separating the reusable knowledge (the DSL implementation) from the product‑specific specifications (the DSL code). The reusable part lives in the DSL implementation, which can be a compiler, interpreter, or code generator, while each product merely writes concise DSL scripts.

Two major design choices for DSLs are discussed: external vs. internal. External DSLs give full freedom over syntax and semantics but require a complete implementation stack (parser, code generator, etc.). Internal DSLs inherit the host language’s syntax and runtime, making them easier to create but limiting expressiveness and potentially complicating interoperability. The authors note that language workbenches (e.g., MPS) aim to reduce the burden of external DSL development by providing meta‑DSLs, projectional editing, and built‑in support for DSL interoperability. LOP languages such as Cedalion aim to combine the best of both worlds: projectional editing and schema enforcement within a single host language.

In the case study, the SPL consists of calculators that share a keypad and display but differ in supported operators, functions, and numeral systems (e.g., hexadecimal). The common functionality to be reused is the parsing of an expression string and its evaluation. The authors deliberately ignore existing DSLs (e.g., Yacc) to emulate a realistic scenario where suitable DSLs are unavailable.

MPS implementation
The authors first design a DSL that combines a context‑free grammar with evaluation rules, reminiscent of attribute grammars. They illustrate the transformation of a left‑recursive “expr ::= expr + multExpr” rule into an LL‑friendly tail‑recursive form to simplify parser generation. The DSL schema in MPS consists of four families of concepts: Rules, Patterns, Reducibles, and Expressions. Concepts are defined via a meta‑model (name, base concept, children, references, properties). For example, a “Concatenation” concept links two patterns, while a “Reducible” binds variables and specifies a resulting expression in curly braces. The DSL relies on MPS’s base language expression concepts (e.g., binary ‘+’) and introduces new concepts for variable references and bound values. Implementation requires writing Java code generators for each DSL construct, configuring projectional editors, and handling the translation from the model to executable Java code. This process gives full control over parsing strategy and runtime performance but incurs a substantial upfront cost in template writing and meta‑model maintenance.

Cedalion implementation
Cedalion uses logic programming to define DSL semantics declaratively. The same four families of constructs are expressed as logical predicates, and a static type system provides schema checking. Projectional editing is delivered as an Eclipse plug‑in, with disambiguation performed at edit time. Because the host language already offers pattern matching, variable binding, and rule evaluation, the DSL implementation consists mainly of logical clauses that directly encode the grammar and evaluation semantics. No separate code generator is needed; the Cedalion runtime interprets the logical rules. This dramatically reduces the amount of boilerplate code and speeds up prototyping. However, Cedalion is a research prototype with limited tooling, documentation, and performance guarantees compared to the mature MPS ecosystem.

Empirical comparison
Both implementations successfully produce a functional calculator SPL. Quantitatively, the Cedalion version required roughly 30‑40 % less development time and fewer lines of DSL‑implementation code. Qualitatively, reuse was achieved in both cases: the DSL implementation was shared across all calculator variants, while each variant’s DSL script was concise. In terms of maintainability, MPS offers stronger static typing, richer IDE features (refactoring, navigation, code generation previews), and the ability to generate standalone Java artifacts, which is advantageous for larger, long‑term projects. Cedalion’s internal DSL approach, while faster to prototype, suffers from limited tool support, dependence on the host runtime, and less straightforward handling of complex parsing scenarios (e.g., LR grammars).

Conclusions
The study concludes that the choice between external and internal DSLs in LOP hinges on project context. External DSLs via a language workbench like MPS are preferable when high expressive power, independent deployment artifacts, and robust tooling are required, and when the organization can absorb the higher initial investment. Internal DSLs via a language such as Cedalion are better suited for rapid prototyping, small teams, or research settings where quick iteration outweighs the need for extensive tooling or performance optimization. By providing a concrete side‑by‑side comparison, the paper supplies practitioners with concrete criteria for selecting an LOP approach that aligns with their reuse goals, resource constraints, and long‑term maintenance considerations.