I upvoted your comment, but the reality is that the grey area is easy to find.
Consider apache's httpd.conf. It includes support for fairly advanced features like conditionals, scopes, and sub-configuration of 3rd party modules. In some environments, for example, it may be quite sensible to include some bits of what might technically be considered "business logic" in something like URL rewrites.
Consider DNS records. Not named.conf, but the actual zone data itself. Is that configuration or is it data? Do you check zone files into a configuration repository with your other files, or do you treat them more like a database to be modified on the fly and just back it up periodically? It probably depends on how dynamic the records are expected to be.
Consider emacs: it uses lisp as its configuration language.
On the other end of the scale, you have very small single-purpose scripts that are easily hand-editable. If you have a script that's no more than 1K, maybe you simply put an "options" section at the top with some defaults that can be changed by modifying the code directly. Or maybe your script is so small that even that amount of overhead is pointless.
It's important to remember that just because there is a grey area doesn't mean that just because you might stuck there, everyone is. But it doesn't mean it can't be confusing sometimes.
Yeah, at a certain point you cross over from configuration into scripting. Emacs Lisp is definitely in the scripting zone, on purpose.
Yes, Apache has a crazy amount of configuration in httpd.conf, and supports conditionals and scopes, to the point where they had to write a syntax checker for it. I would actually consider httpd.conf a good example of the "softcoding" anti-pattern.
A certain amount of configuration is good, and deliberately providing a scripting DSL language for your program is also good if appropriate.
But when you inadvertently cross over from normal configuration into absurdly complex configuration that resembles a crappy scripting language, giving you the feeling that you're in this big grey area between code and config, that's an anti-pattern.
Consider apache's httpd.conf. It includes support for fairly advanced features like conditionals, scopes, and sub-configuration of 3rd party modules. In some environments, for example, it may be quite sensible to include some bits of what might technically be considered "business logic" in something like URL rewrites.
Consider DNS records. Not named.conf, but the actual zone data itself. Is that configuration or is it data? Do you check zone files into a configuration repository with your other files, or do you treat them more like a database to be modified on the fly and just back it up periodically? It probably depends on how dynamic the records are expected to be.
Consider emacs: it uses lisp as its configuration language.
On the other end of the scale, you have very small single-purpose scripts that are easily hand-editable. If you have a script that's no more than 1K, maybe you simply put an "options" section at the top with some defaults that can be changed by modifying the code directly. Or maybe your script is so small that even that amount of overhead is pointless.
It's important to remember that just because there is a grey area doesn't mean that just because you might stuck there, everyone is. But it doesn't mean it can't be confusing sometimes.