The gist of it is researchers needing to design flows of arbitrary complexity to gather data, that can be composed together in many ways and might change over t

The gist of it is researchers needing to design flows of arbitrary complexity to gather data, that can be composed together in many ways and might change over time (and need to be versioned), with a strong graphical component to it. Yes, I could have embedded Lua or Python or JS and made them interact with an API that the environment exposes, but designing my own DSL let me make it a declarative affair, which greatly simplified things, as well as take various shortcuts in representing some abstractions that'd have been much more of a pain otherwise. This was in a CPU/memory bound environment, where the declarative, compact DSL approach (with all of the properties of the resulting program inferrable at parse time) turned out to work quite well. And generating that DSL is much more straightforward than generating code in a full scripting language. The graphical editor was indeed a big reason for the success, and my users didn't interact with the DSL, but my developers did and it was much more straightforward for them than having to deal with lua/Python/etc. Ultimately we'd have still ended up with a DSL, albeit one represented in a programming language where 99% of the features are unused. I'm not sure I get why you're so opposed to the notion altogether. Sure, there's plenty to quibble with if one so desires with OP's implementation in a vacuum, but perhaps consider that people just as experienced and knowledgeable as you have found value in the DSL approach over others for certain projects. If you're interested in diving more into it, check out Fowler's book.