As someone who's had a love-hate thing with domain-specific languages - reading your story was a good learning experience. There's great value in sticking with

As someone who's had a love-hate thing with domain-specific languages - reading your story was a good learning experience. There's great value in sticking with "inert" data formats like XML or JSON, which have standard parsers in most languages, developed over years. Once data crosses over into code, there's a whole host of potential issues to consider, including the requirement of an interpreter/compiler and a sandboxed environment, with all that entails. The Emscripten config needing Python is a perfect example. Another example I thought of, is Markdown and MDX. The latter allows the use of JavaScript and React components mixed with markup, for dynamic content. It's brilliant in its own way, but I'm wary of using it as a document format precisely because it's no longer just data. Documents in MDX can't be consumed by other languages, and will always require the full JS/React environment. Tcl actually feels like it could reasonable to use for data, due to its ubiquity/longevity. Lua, or better yet some kind of Lisp, also seem attractive as a serialization format. The interpreter could be small and stable, and the latter at least might even be simpler to parse than XML or JSON. > We still have to drag a stripped down Tcl interpreter along in our asset pipeline 20 years later because it's nearly impossible to switch away This makes me see how the decision created a long-term dependency to a language, where the data was no longer in a portable format. Good to keep this in mind next time I'm tempted to allow data to become code.