> you still have much more control over what can and cannot be executed by the config engine, even if the DSL happens to accidentally become Turing complete
Turing completeness is a red-herring when it comes to config languages IMHO. Purity is much more important consideration, e.g. to ensure it can't delete files, or vary its output based on random network calls.
Besides, there is no true Turing complete languages as we are dealing with finite computers.
So my preference is to have a simple language with explicit limit on number of operations and the amount of memory its interpreter can access before aborting rather than a complex config without any explicit limits on complexity leading to exploits with stack or memory overflow in pathological cases.
> Besides, there is no true Turing complete languages as we are dealing with finite computers.
This is not true. Turing complete languages are so because their halting problem is undecidable, it is irrelevant that the computer you run a python program has finite memory. Check out languages like Agda where you can do general purpose computing but are not Turing complete, since all programs can be proved to halt.
Turing completeness is a red-herring when it comes to config languages IMHO. Purity is much more important consideration, e.g. to ensure it can't delete files, or vary its output based on random network calls.