[joshuamorton]

using Turing complete languages for configs is a mistake.

Configs are hard, and they're different to enough from normal software (for example DRY doesn't apply in the same circumstances) that using the same tools is a bad idea.

I've seen what happens when swes use swe languages on configs. They get unintelligible. And then I have to clean up the messes.

To be clear though, using Json or toml for configs is also often a mistake.

[argd678]

The problem is that the declarative model doesn’t fit, so in Terraform for example they’ve added branching and for loops even, so you’re making a language at that point. But rather than keeping the logic and the data structure separate, they’re mixed up with each other. This is a solved problem in many languages, Java especially.

I think a valid question would be what is the right framework factoring or design should be, but pure declarative isn’t not and half declarative like Terraform are just repeating past mistakes.

[TeMPOraL]

> for example DRY doesn't apply in the same circumstances

Doesn't it, though? Dumb configs tend to suffer very much because of the impossibility to apply DRY directly, and people end up using/writing config generators just to ensure consistency of values.

Hell, isn't half of the job of a IaC tool to be such a config generator, papering over lack of capabilities of configuration languages?

[joshuamorton]

>Doesn't it, though?

Theoretically, maybe. In practice, I don't think so. Mostly because code is much less prone to change than configs are. Like if you have some encapsulated set of behavior in code, it's often easy (and not particularly painful) to do something like

    self.thing = x if self.other else default

This is (normally) fine. Sometimes this will expand to be 2-3 different things. So you might get

    if self.other:
       self.val = ...
    elif self.different_situation:
       self.val = ...
    else:
       self.val = default

And this avoids setting self.val in all of the child classes, it's "nice and DRY".

Because code-code doesn't change that much, this kind of weird gross encapsulated behavior is (usually) ok. It's still a code-smell, but you don't get burned by it. But when you are dealing with configs, they do change, and you want to be extra explicit, because (as you probably know), the number of exceptions and special cases will inevitably grow, and you'll end up with implicit leaf-level configuration hidden away in your so-called encapsulated stuff, but without end-user visibility into what is actually happening.

One solution to this is to completely ignore DRY and ensure consistency via unit tests or static analyzers or something, but that also sucks (possibly more) than doing some denormalization within your config-language itself.

My experience says the right way to do this is to restrict yourself to not using any conditionals other than perhaps get-with-default, and doing everything that would be done conditionally via inheritance or composition. Remains to be seen if I think I made the right decision 5 years from now.

[argd678]

These inheritance constructs are either missing or too ridged in the current tooling to be able to use those patterns unfortunately. Java in a lot of ways seems like an ideal language, especially with AOP, where for example you could use exactly the same code and swap out the cloud provider.

[joshuamorton]

I agree that most languages are bad for this. I think Java is also too verbose to be a good config language. My experience has been with a Python dsl but I'm open to other options too.

[argd678]

I actually see it less as a configs language issue and more that you want a program that encapsulates the patterns and logic for your app to run. So the language itself is a bit less of an issue other than it needs to support the model you’re creating.

[scarface74]

CF supports macros and custom transforms that can be written in any language.