Hacker News Reader

Comment by tantalor | Hacker News Reader

Using programming languages for configuration is a bad idea.

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.

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.

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

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.

Static declarations without a reason are equally bad.

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.

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.

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

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.

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

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.

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.

Emacs would like a word. :)

gradle has entered the chat

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.

Gradle does suck though.

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.

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.

Reply on news.ycombinator.com