[qppo]

The middle ground of DSLs is to consider that to realize a DSL one must have an AST, and an AST is the ultimate data representation for complex business logic, allowing for (almost literally) infinite degrees of introspection or analysis, as well as synthesis of artifacts to be consumed by other tools or individuals in the business (as in compiling reports, generating spreadsheets, and all sorts of intermediary data).

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.

[brundolf]

My impression (strengthened by your argument) is that nearly anything we can say about a DSL we can say about data in general (as opposed to code). A DSL at the end of the day is just a specialized, idealized schema for data representation. Most of its advantages would also apply (in varying degrees) to storing business information as JSON, or in SQL tables, or as s-expressions for that matter. In any of these cases we get the same benefits of portability, introspectability, automation, etc.

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.

[jolmg]

> to realize a DSL one must have an AST

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.