Comment by saidajigumi

IMO, your comments belie the entire experience of library developers in "DSL-friendly" languages; those with a system of language features that compose well to create what humans perceive as "sub-languages". Ruby and Haskell come to mind immediately, each with a very different set of DSL-enabling attributes.

"The chances your DSL is going to be good is very low." – Nonsense? Yes, API design can be hard. But DSL design at the scale of embedded, ergonomic DSLs is most commonly exactly the same scale as API design. Moreover, there are plentiful examples to draw from these days, especially around builder-type APIs as illustrated in the article. We have quite a suite of well-established patterns to draw from, and they're just not that hard to apply well.

Notably, "language design" doesn't come into it. Almost all proper "language design" decisions for these kind of DSLs are made by the host language – that's why embedded DSLs are so appealing in the first place. There are exceptions when the "language" is really a language (e.g. embedding a Prolog in Haskell or whatever), but most of the DSL examples in the wild end up simply being nice ways to construct rich data structures for consumption/interpretation by some utility library.