Hacker News new | ask | show | jobs
by rm445 4453 days ago
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.
3 comments
jt2190 4453 days ago 

  > 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.

link
AdrianRossouw 4453 days ago
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/

link
theseoafs 4453 days ago
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.
link