4 ms·

Using programming languages for configuration is a bad idea.

bryanrasmussen 5y ago
why? It can't be because then if something goes wrong you need to debug your configuration, because you need to do that often enough with a non-programming language format for even less power offered.
- krapp 5y ago
  If your config is so complex that it needs "debugging" then it's too complex. The reason you don't want to use a programming language for configuration is that configuration shouldn't be programming - configuration should be idempotent, it should describe a state, and it should contain only data, and structures of data (arrays, maps, sets, what have you.) No functions, no classes, no mutability. If you use a programming language as configuration, the temptation to make your configuration more and more complex, and add features and "shortcuts" to integrate it more deeply with your application will be irresistible, and eventually your config will need its own config, which will eventually grow to need it's own config, ad infinitum. And I say this as someone who advocates using Lua tables for config in gamedev, if you're not willing to be disciplined with avoiding Turing creep at all costs, don't do it.
taeric 5y ago
Emacs would like a word. :)
latchkey 5y ago
Static declarations without a reason are equally bad.
inoffensivename 5y ago
gradle has entered the chat
- deschutes 5y ago
  Gradle does suck though.
  - l_r 5y ago
    Why do you think so? I couldn’t disagree more. Task caching/avoidance, rich build domain model (source sets, configurations, tasks, extensions), huge plugin ecosystem.
    - deschutes 5y ago
      My opinion is based on my experience integrating artifact generators (both code and config) into a build. I recall being funneled into building a plugin by documentation to deal with some idiosyncrasies of the generator. Whereas I just wanted to write a small script. In general I felt like there were a lot of extra hoops and concepts to learn to do basic easy shit. And there really isn't any payoff. For example I recall scripts and plugins have different capabilities. And that some things can't be expressed in untyped Gradle. I also found that the user documentation was just a skosh above useless. It felt like it was more concerned with not being wrong than being helpful. Reminiscent of older javadocs in the java collections library. The same could be said of many build systems, I suppose.
- kaba0 5y ago
  You are not supposed to write actual build logic inside gradle though, as many people do. It is supposed to be a DSL for build scripts the same way maven is, with slight ease of use scripting.
rectang 5y ago
Couldn't agree more — a hard requirement for a configuration language is that it must be inert. Under some circumstances, configuration needs to be generated dynamically so you need a programming language — and TypeScript would be fine for that. But a "perfect" configuration format isn't perfect if it can run arbitrary code.
- cout 5y ago
  Many years ago, I had the idea of using Ruby as a configuration language. It lends itself nicely to representing tree structures and has some convenient features like ranges. It all worked well as long as we stuck to the subset of Ruby I intended. One day one of the other developers introduced a change to the configuration that had a side effect. It made sense; after all, the configuration is read at startup, so surely it makes sense to put code there that you want to have run at startup? You can imagine my surprise when I made change that read the configuration again after startup. Configuration should be purely functional and idempotent, with no side effects, or as you say, inert.
threatofrain 5y ago
Then should we should do what the industry does instead — start with a flat configuration language like YAML and then add modules, variables and scopes, iteration... And what do we do when we want the Cartesian product of two sets? Ahem Terraform.
IshKebab 5y ago
Why? The only reasons I can think of are: * They can be non-deterministic (do a different thing each time you run them). * They can be non-hermetic (access stuff in the environment you don't know about). * They can do naughty security things. * You can't present GUIs of them because they aren't declarative. All but the last one don't exclude programming languages. Here's an interesting project to make hermetic deterministic Javascript (Typescript support is planned): https://github.com/jkcfg/jk https://github.com/jkcfg/jk For the sorts of places where you don't have a GUI for the settings anyway (which is the common case) I think it makes loads of sense. It beats making the kind of declarative programming languages you see in YAML files.
int_19h 5y ago
Using pure programming languages for configuration is fine. The trick is that the config "program" should basically just output the final - static - configuration, and set of inputs should be very strictly controlled (i.e. no opening random files etc).
AtlasBarfed 5y ago
Except that a programming language provides: - types if you want them - IDEs/tooling/a kind of UI-out-of-the box - often other useful toolchain programs for packaging, management, etc - a well defined syntax - and the big bertha for REALLY COMPLICATED config: autocomplete in your tool/ide/etc - and yeah, turing complete dropouts, meta configuration frameworks for generating config
1_player 5y ago
Using static file formats for configuration is wishful thinking for projects that are perfectly specified on day 1 and whose requirements never, ever change. I'd rather choose a bad idea than having to reimplement a Turing-complete programming language in YAML a few years down the line.
kazinator 5y ago
Indeed, configuration should specify only state, never new behavior. For instance: [plugin "foo"] binary = "C:\\Program Files\\Foo\\Foo.DLL" Heaven help you if you cave into temptation and think it's a good idea to dynamically calculate this string with code, like to track varying install location and such.

why? It can't be because then if something goes wrong you need to debug your configuration, because you need to do that often enough with a non-programming language format for even less power offered.

krapp 5y ago
If your config is so complex that it needs "debugging" then it's too complex. The reason you don't want to use a programming language for configuration is that configuration shouldn't be programming - configuration should be idempotent, it should describe a state, and it should contain only data, and structures of data (arrays, maps, sets, what have you.) No functions, no classes, no mutability. If you use a programming language as configuration, the temptation to make your configuration more and more complex, and add features and "shortcuts" to integrate it more deeply with your application will be irresistible, and eventually your config will need its own config, which will eventually grow to need it's own config, ad infinitum. And I say this as someone who advocates using Lua tables for config in gamedev, if you're not willing to be disciplined with avoiding Turing creep at all costs, don't do it.

taeric 5y ago

Emacs would like a word. :)

latchkey 5y ago

Static declarations without a reason are equally bad.

inoffensivename 5y ago

gradle has entered the chat

deschutes 5y ago
Gradle does suck though.
- l_r 5y ago
  Why do you think so? I couldn’t disagree more. Task caching/avoidance, rich build domain model (source sets, configurations, tasks, extensions), huge plugin ecosystem.
  - deschutes 5y ago
    My opinion is based on my experience integrating artifact generators (both code and config) into a build. I recall being funneled into building a plugin by documentation to deal with some idiosyncrasies of the generator. Whereas I just wanted to write a small script. In general I felt like there were a lot of extra hoops and concepts to learn to do basic easy shit. And there really isn't any payoff. For example I recall scripts and plugins have different capabilities. And that some things can't be expressed in untyped Gradle. I also found that the user documentation was just a skosh above useless. It felt like it was more concerned with not being wrong than being helpful. Reminiscent of older javadocs in the java collections library. The same could be said of many build systems, I suppose.
kaba0 5y ago
You are not supposed to write actual build logic inside gradle though, as many people do. It is supposed to be a DSL for build scripts the same way maven is, with slight ease of use scripting.

rectang 5y ago

Couldn't agree more — a hard requirement for a configuration language is that it must be inert. Under some circumstances, configuration needs to be generated dynamically so you need a programming language — and TypeScript would be fine for that. But a "perfect" configuration format isn't perfect if it can run arbitrary code.

cout 5y ago
Many years ago, I had the idea of using Ruby as a configuration language. It lends itself nicely to representing tree structures and has some convenient features like ranges. It all worked well as long as we stuck to the subset of Ruby I intended. One day one of the other developers introduced a change to the configuration that had a side effect. It made sense; after all, the configuration is read at startup, so surely it makes sense to put code there that you want to have run at startup? You can imagine my surprise when I made change that read the configuration again after startup. Configuration should be purely functional and idempotent, with no side effects, or as you say, inert.

threatofrain 5y ago

Then should we should do what the industry does instead — start with a flat configuration language like YAML and then add modules, variables and scopes, iteration... And what do we do when we want the Cartesian product of two sets? Ahem Terraform.

IshKebab 5y ago

Why? The only reasons I can think of are: * They can be non-deterministic (do a different thing each time you run them). * They can be non-hermetic (access stuff in the environment you don't know about). * They can do naughty security things. * You can't present GUIs of them because they aren't declarative. All but the last one don't exclude programming languages. Here's an interesting project to make hermetic deterministic Javascript (Typescript support is planned): https://github.com/jkcfg/jk https://github.com/jkcfg/jk For the sorts of places where you don't have a GUI for the settings anyway (which is the common case) I think it makes loads of sense. It beats making the kind of declarative programming languages you see in YAML files.

int_19h 5y ago

Using pure programming languages for configuration is fine. The trick is that the config "program" should basically just output the final - static - configuration, and set of inputs should be very strictly controlled (i.e. no opening random files etc).

AtlasBarfed 5y ago

Except that a programming language provides: - types if you want them - IDEs/tooling/a kind of UI-out-of-the box - often other useful toolchain programs for packaging, management, etc - a well defined syntax - and the big bertha for REALLY COMPLICATED config: autocomplete in your tool/ide/etc - and yeah, turing complete dropouts, meta configuration frameworks for generating config

1_player 5y ago

Using static file formats for configuration is wishful thinking for projects that are perfectly specified on day 1 and whose requirements never, ever change. I'd rather choose a bad idea than having to reimplement a Turing-complete programming language in YAML a few years down the line.

kazinator 5y ago

Indeed, configuration should specify only state, never new behavior. For instance: [plugin "foo"] binary = "C:\\Program Files\\Foo\\Foo.DLL" Heaven help you if you cave into temptation and think it's a good idea to dynamically calculate this string with code, like to track varying install location and such.