Earlier quoted context omitted.
It is nuclear overkill for most problems you can think of. But when you hit a problem that you need something like this for... you need something like this. The attempts to get around it or avoid it or do some unbelievably hacky thing leads to piles and piles of terrible, terrible code. In 2024, though, I do try very hard to embed my DSLs in an existing serialization. It doesn't always work out, but, the case they sh…
To be clear, my problem isn't with requiring a single DSL, it's with writing so many DSL's at work that there's need for a DSL writing framework to crap them out even faster. At what point do you sit back and ask, is there a way to reduce complexity here? Is it not until you're joining a team where the last guy made dozens of DSL's for all his tools? That was the main reason I was expecting more than a few real world…
Yes, you can generate your test data in the host language. That dramatically reduces upfront complexity.
But that doesn't come free. Now it is not easily transferrable to other languages. If you recall rsc's somewhat recent talk on testing, they benefited greatly by being able to use similar DSLs from other projects in tests to ensure feature parity. It can be a huge boon to have your test data scripts in an "agnostic" language for 30 years down the line when you are no longer working in the same environment.
Tradeoffs, as always.
> I was expecting more than a few real world use cases
Maybe that's the only use-case they know of? The project was clearly built for a specific purpose.
That's not to say that it cannot be found useful elsewhere, but that doesn't mean they have found it to be. If someone else finds it useful in other applications, I'm sure they'll write their own document about it. That's what the web is for, after all.