you need to develop the sense to know that just because something could be made configurable doesnt mean it should be.

what software doesn't do is often as important as what it does do.

  > you need to develop the sense to know that just because 
  > something could be made configurable doesnt mean it 
  > should be.

That doesn't explain why one shouldn't use a programming language when things are configurable.

I don't know where that line is, honestly.

I'm still trying to figure it all out myself, but it feels like the line is drawn around the time that you find that the order of configuration options starts to matter, and probably also when start conditionally loading code based on it.

So it's something like the divide between "let's keep this in a variable because we might need to reference later", and "let's store this in a variable because we need to alter control flow based on it".

Hopefully I will know how to tell the difference someday.

> the order of configuration options starts to matter

Commutativity (and idempotency) are too important traits of declarative languages and they are at odds with turing-completeness: I have the feeling a lang can't be declarative turing-complete and efficient (finish in a reasonable time) at the same time.

So you pick two: efficient and declarative or efficient and turing-complete. Once you go turing complete anyway you can't guarantee termination and reasoning about programs becomes hard.

I'll take a stab at it, please feel free to critique.

All my reasons come down to complexity. Competing against our righteous need to make software do cool stuff, is the fact that everyone writes software that breaks all the time. Configuration that can perform arbitrary computation can put our programs into literally any state, making it that much harder to make them robust and correct.

It also opens up the risk that people won't configure their software correctly because they don't understand the configuration. And it even opens up attack vectors - what if there's a buffer overflow in your configuration interpreter, or a resource link that lets configuration files do arbitrary things to a system?

But I think one of the biggest risks is fragility. Configuration files that can do arbitrary computation will be made to do so. Software that gets used by lots of people will end up with towers of complexity built into the configuration, to the point that removing or refactoring them risks bugs, edge cases, or breaking a particular feature or misfeature that someone relies on. Better to control the complexity in the first place.

  > Configuration that can perform arbitrary computation can 
  > put our programs into literally any state...

Considering that it's generally a poor design that expose the full state of an application to all parts of the same application (think: "global state"), then yes, it holds that exposing the entire application state to the configuration system is also a very poor design. I would think that if a user could set three values via configuration, then those three values would be the only state exposed.

  > It also opens up the risk that people won't configure 
  > their software correctly...

We can always find someone who can't configure the system, regardless of how the configuration is done. If we're worried about making configuration "safer", then the system should be more careful about what configuration values it accepts i.e. implement robust validation.

  > But I think one of the biggest risks is fragility. 

Systems that can't adapt to unanticipated needs of their users get replaced by systems that can adapt. It's why many pieces of mature software develop this robust configuration ability (often hiding under the label "api", "scripting interface", "plugin framework", etc.)

  > Software that gets used by lots of people will end up with 
  > towers of complexity built into the configuration, to the 
  > point that removing or refactoring them risks bugs, edge 
  > cases, or breaking a particular feature or misfeature that 
  > someone relies on.

This is not a inevitable. Many mature systems have successfully incorporated fully programatic configuration [1] without turning into "towers of complexity". (It probably says something about the application's architecture if it's so tightly coupled to it's configuration.)

[1] Unix is the poster child for this.

Essentially that. That simple/easy terminology I mentioned before actually has this as one of it's conclusions:

http://daemon.co.za/2014/03/how-complexity-affects-software/

You don't really have to worry about any of this if you use a proper interpreter for your configuration files (for example, if you do configuration by embedding Lua in your application, which is very common and useful). If you try to build up a programming language from scratch, you're right that you're going to have problems, but embedding a battle-tested, safe language means you don't have to worry about your program being put in "literally any state" or your program being susceptible to buffer overflows.

It's a recipe for shooting yourself in the foot.

https://en.wikipedia.org/wiki/Rule_of_least_power