5 ms·

To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pai

To me, worrying about config files seems like the ultimate exercise in bikeshedding. You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. Or you need templating, the use of functions, etc, like dhall provides. But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Might sound like I'm throwing sourness around, but I just don't see the niche for this, except inventing a new thing for the joy of it?

afiori 7y ago
One reason is that "configuration language" is an extremely wide topic. Some configs use yaml to encode bash scripts for example. Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Honestly it is the reason I like TOML, with the exception of the date data type it cleanly maps to json (which everyone agrees it is a good enough serialization format) and it is specifically focused on human friendliness (except uniform lists) and readability As an underappreciated feature, the ability to have scoped keyvalues allow to define nested table with flat statements.
- isoprophlex 7y ago
  > Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Okay thanks, that's a good one. Readability might be a big deal.
zeliard 7y ago
>But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Well, for same reason, say, why people would use a javascript framework to build a webapp over vanilla js. Both could do the job, and for simple cases there's little reason to go with a framework resp. specialized config language. But as your app/config gets larger and more complex, using a framework resp. config language would tend to get the job done more efficiently by providing you structure and toolbox with solutions to common pain points. Config generators themselves tend to be a rather heavyweight all-or-nothing solution which leads people to compromise on some adhoc middle-ground solutions like YAML with jinja templates with unclear evaluation semantics. A good config language designed from the ground up can be so much better than this unholy yaml/jinja mess! Finally, one of the key selling points of specifically Dhall is type checking. Implementing that in config generators in a generic untyped scripting language would be a nontrivial amount of boilerplate, and boilerplate elimination is what config languages are all about.
GordonS 7y ago
I kind of agree, to a point (e.g. Erlang config is, usually, a complete shitshow). I wonder if JSON had allowed for comments if we'd see such a proliferation of config system? At least IME, that seems to be the biggest pain point with JSON.
leg100 7y ago
> You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. You clearly haven't wrestled with kubernetes configuration files. Reams and reams of YAML, heavily indented to represent umpteen nested objects. Templating, bash scripts, using your favourite language to roll your own config generator - these are all well trodden approaches that fail to scale. Official shitshows like Helm have come along with nothing more innovative to offer than templated YAML. The next version uses lua to generate config, but I remain skeptical given previous design choices. We can question whether kubernetes has pushed the dial too far towards necessitating mountains of config, but for now it is most definitely a problem for us users.
- mbrock 7y ago
  My favorite is when people write scripts that concatenate YAML files in such a way that you have to be really careful about how this one file always needs to be indented by 12 spaces otherwise everything breaks in horrible ways.
guggle 7y ago
My thoughts, exactly. Especially with dynamic, scripting languages with no need for compilation and simple enough syntax (ie. php, python, ruby, etc). Why would I want to add another layer of complexity to an application with an unknown language while I already have a capable one ? Why add more dependencies on your project ? Why add more cognitive load on your brain ?

afiori 7y ago

One reason is that "configuration language" is an extremely wide topic. Some configs use yaml to encode bash scripts for example. Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Honestly it is the reason I like TOML, with the exception of the date data type it cleanly maps to json (which everyone agrees it is a good enough serialization format) and it is specifically focused on human friendliness (except uniform lists) and readability As an underappreciated feature, the ability to have scoped keyvalues allow to define nested table with flat statements.

isoprophlex 7y ago
> Overall a reason enough is that human-friendly languages have different priority than parser-friendly ones. Okay thanks, that's a good one. Readability might be a big deal.

zeliard 7y ago

>But then, why not use the language you're already using for the rest of your project, or a bash script to export some variables? Well, for same reason, say, why people would use a javascript framework to build a webapp over vanilla js. Both could do the job, and for simple cases there's little reason to go with a framework resp. specialized config language. But as your app/config gets larger and more complex, using a framework resp. config language would tend to get the job done more efficiently by providing you structure and toolbox with solutions to common pain points. Config generators themselves tend to be a rather heavyweight all-or-nothing solution which leads people to compromise on some adhoc middle-ground solutions like YAML with jinja templates with unclear evaluation semantics. A good config language designed from the ground up can be so much better than this unholy yaml/jinja mess! Finally, one of the key selling points of specifically Dhall is type checking. Implementing that in config generators in a generic untyped scripting language would be a nontrivial amount of boilerplate, and boilerplate elimination is what config languages are all about.

GordonS 7y ago

I kind of agree, to a point (e.g. Erlang config is, usually, a complete shitshow). I wonder if JSON had allowed for comments if we'd see such a proliferation of config system? At least IME, that seems to be the biggest pain point with JSON.

leg100 7y ago

> You either need a simple list of items (eg. dependencies) or key/value pairs. Use a text file or yml or json or whatever. You clearly haven't wrestled with kubernetes configuration files. Reams and reams of YAML, heavily indented to represent umpteen nested objects. Templating, bash scripts, using your favourite language to roll your own config generator - these are all well trodden approaches that fail to scale. Official shitshows like Helm have come along with nothing more innovative to offer than templated YAML. The next version uses lua to generate config, but I remain skeptical given previous design choices. We can question whether kubernetes has pushed the dial too far towards necessitating mountains of config, but for now it is most definitely a problem for us users.

mbrock 7y ago
My favorite is when people write scripts that concatenate YAML files in such a way that you have to be really careful about how this one file always needs to be indented by 12 spaces otherwise everything breaks in horrible ways.

guggle 7y ago

My thoughts, exactly. Especially with dynamic, scripting languages with no need for compilation and simple enough syntax (ie. php, python, ruby, etc). Why would I want to add another layer of complexity to an application with an unknown language while I already have a capable one ? Why add more dependencies on your project ? Why add more cognitive load on your brain ?