You've already lost big if you ever need a debugger to understand code. Especially if your beginners have to use it just to wrap their head around wtf is happening.

And having to run your "config files" just to see what they're doing is the huge downside of using programming languages as config. In other words, it's kind of circular to point out that using code for config puts you in a situation where you might have to use a debugger to know what your config does.

You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs?

There’s a middle ground that you see with a number of test frameworks, Gulp, SCons and I suspect with Pulumi, where the outer shell of imperative code is in practice declarative, and the inner bits are properly imperative.

Part of the code says why to do something, and the rest says how to do it. For instance I don’t see a huge conceptual difference between disabling or filtering a test, versus not deploying a service because it is running, current, and healthy.

> You’ve never told (or been) a new employee to step through the code to figure out what isn’t in the docs?

To me that sounds like a failure state.

But isn't the output of this declarative config files?

Now? You're probably right.

If you proxy to replace it might not have to stay that way. But the Lava Flow Antipattern is what happens when momentum fails before the work is complete.