DSLs are often described as enabling 'executable' or 'generative' models. What's the practical difference between those two ways of making a DSL model actually do something, and what trade-offs come with each?

## Two routes from a model to behavior Both 'executable' and 'generative' describe ways of turning a DSL model - the typed, in-memory structure a parser and scope resolver produce from DSL source text - into actual runtime behavior, but they take fundamentally different routes to get there. - An **executable (interpreted) model** is run directly: a runtime component, the interpreter, walks the model's structure - its elements, features, and cross-references - at execution time and performs the corresponding action for each node, the same way a tree-walking interpreter for a general-purpose language executes an AST without ever compiling it to machine code first. Nothing intermediate is produced; the model itself, unchanged, is the thing that runs. - A **generative model** instead treats the DSL model as input to a separate transformation step, a code or artifact generator, typically implemented with a template engine (Xtend templates in the Xtext ecosystem, or comparable tools elsewhere) that walks the model and emits text in some target language or format - Java source, SQL DDL statements, YAML configuration, Terraform HCL. That generated artifact is then compiled, deployed, or otherwise consumed through the target ecosystem's own normal toolchain, entirely independent of the DSL's own runtime. ## Why both patterns exist The reason both patterns exist, rather than one dominating, is that they solve different halves of the model-driven development promise. The whole premise of building a DSL and a supporting metamodel is that domain concepts, once captured formally, should be able to *do* something rather than sit inert as documentation - that's the 'executable' half of the promise, and interpretation is the most direct way to deliver it: point a runtime at the model and it behaves. The 'generative' half of the promise is about leverage into an existing ecosystem: rather than reinventing a runtime, a persistence layer, an optimizer, and a deployment pipeline for every DSL, generation lets the DSL model drive an already mature target platform's tooling, gaining that platform's performance, debugging tools, and operational maturity essentially for free. ## The central trade-off The central trade-off is iteration speed and directness versus native performance and toolchain integration. | | Executable (interpreted) | Generative | | --- | --- | --- | | Feedback | near-instant: change the model, rerun, see the new behavior | an added build step between changing the model and seeing the effect | | Runtime | an interpreter walking a generic model tree, almost always slower at runtime | a native artifact that runs through the target platform's existing compiler and optimizer | | Artifact | the model itself, unchanged, is the thing that runs | generated source that can be inspected, diffed, and code-reviewed | | Failure mode | the debugging gap | the round-trip problem | Interpretation gives near-instant feedback: change the model, rerun, see the new behavior, with no compile step in between, which is exactly what you want while a language's semantics are still being designed and iterated on rapidly. But an interpreter walking a generic model tree is almost always slower at runtime than compiled, optimized target code, and it means your DSL now owns its own execution semantics and performance characteristics forever, separate from whatever the target ecosystem already offers. Generation instead produces a native artifact - real Java classes, real SQL - that runs through the target platform's existing compiler, optimizer, and operational tooling (monitoring, profilers, deployment pipelines built for that platform), and the generated source can be inspected, diffed, and code-reviewed like any other artifact. The cost is an added build step between changing the model and seeing the effect, and a structural risk unique to generation: what happens when someone edits the generated file directly. ## The round-trip problem, and the debugging gap That structural risk is the 'round-trip problem,' and it's the most common and most damaging failure mode on the generative side. If a developer opens a generated Java file and manually adds a custom method or fixes a bug directly inside it, that edit survives only until the model changes again and the generator reruns - at which point the entire file is regenerated from the model and the manual edit is silently overwritten with no warning, because the generator has no idea a human ever touched that file. Teams mitigate this with a few standard patterns: - designating explicit 'protected regions' in the generator's templates that it will preserve across regenerations and leave untouched; - generating only scaffolding, interfaces, or partial/abstract classes that hand-written code extends or implements in a separate, never-regenerated file; - or, most simply, treating every generated artifact as fully disposable and enforcing, by convention or tooling, that it is never hand-edited at all. The corresponding failure mode on the executable side is a debugging gap: standard debuggers are built to step through the host language's own bytecode or source, not an arbitrary DSL's semantic model, so debugging an interpreted DSL either requires a custom, DSL-aware debugger and stepper (a significant engineering investment in its own right) or falls back to inspecting raw interpreter internals, which is far less ergonomic than debugging familiar, generated source. ## Interpret while designing, generate for production In practice, mature model-driven development setups frequently use both, deliberately, at different points in the same project's lifecycle: interpretation during active design and debugging, when the model's semantics are still in flux and instant feedback is worth more than performance; generation once the design has stabilized and the artifact needs to be deployed, monitored, and operated using the target platform's normal, mature tooling. A concrete illustration is a state-machine or business-rules DSL used first via an interpreter inside the modeling tool itself so a domain expert can immediately see a rule's effect while authoring it, and later compiled via a code generator into native Java classes for production deployment, where startup latency, throughput, and integration with the existing monitoring stack matter far more than how quickly the last edit took effect.