Has anyone seen a study on "how a DSL becomes a GPL"? Or, alternatively, "what is the most common path travelers take before arriving at Greenspun's 10th rule?" Is there something like "DSLS either die or eventually add identifiers, then functions, then branching, then macros, etc"? I'm curious if you can look ahead and say "well if this is successful, it will eventual require so many things, so might as well not do a DSL in the beginning and instead start with a GPL and build a library"

I know only https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html but that's not an actual study... 😅

I've never seen it studied, but I've seen it happen over and over. This is why DSLs should be embedded in real programming languages. https://twitter.com/jackrusher/status/1348645505811828737

It's unfair that there is a 💯 emoji but not one for 50% agreement! My first question when choosing embedded vs. standalone for a DSL is: is the stuff that you encode using the DSL more like "code" or more like "data"? In the former case, go for embedded (for the reason @Jack Rusher gave). In the latter case, go for standalone in order to keep your data independent of a single language ecosystem, and thus more widely usable. There is of course no clear borderline between code and data, all code being data from another point of view. But in the context of a specific domain, the choice is often obvious.

@Konrad Hinsen The line between code-like and data-like for me is whether or not the data will be interpreted (in the abstract interpreter sense) and thus encodes computation. If one is — for example — just writing a bunch of sensor readings from an experiment, one might as well do it as packed binary data frames. Whereas, if one is creating a specification/configuration language that includes constructs for things like conditionals and loops/recursion, it's already too late — just use scheme/Smalltalk/FORTH and be done with it. 😊

Exactly. I thought a lot about this because my current project in DSL space is very much on the borderline. Leibniz (https://github.com/khinsen/leibniz-pharo) is a domain-specific specification language, which does include conditionals etc. (it's a term rewriting system). But its reaon for existence is the documentation of computational models for humans, independently of any concrete implementation in code, so I ended up choosing the standalone approach explicitly to remove the temptation of the quick hack in whoever's favorite programming language of the day.

It all depends on intention, and it's worth being very conscious of one's intentions and drawing a hard line in one's mind between a configuration format and a DSL. The world is awash in configuration formats that slowly accumulated features and backed into Turing-completeness. A classic example is Apache configuration. Google Analytics is another one. YAML might also qualify, though I don't recall if they intended to make it Turing-complete from the start. That's one advantage of embedding in a real language: no illusions. You can't slide down a slippery slope if you start at the bottom.