The language could be provided by the platform provider (e.g a simple language for expressing website UI/UX), or it could be completely ad hoc, designed by a non technical user, with the help of a technical user or a graphical tool perhaps.
Armed with a newfound expressive language designed by themselves, a non technical user could go to town building whatever they wanted, instead of being bogged by the limitations and learning curve of a nocode tool.
If you can't buy into a DSL, consider thinking about your data as an AST, and the usage of that data as compiling it for various targets.
Users can be hesitant to adopt DSLs. They aren't that hesitant to adopt the extreme amounts of automation that a DSL can give you, and having a structured representation in the form of an AST reduces a lot of friction when developing business automation as compiler passes over it.
That's not to say that DSLs are useless. In many cases they have advantages against the above formats in terms of both what they can, and (just as important) can't, express. I just think they're part of a bigger conversation.
Not necessarily. I think a parser combinator library counts as a DSL. Yet, the result from using that DSL is normally a function that you run to parse from sources. IOW, the DSL functions take functions and return functions built from them. You can't introspect that.
