4 ms·

I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze

by nikeee 1y ago

I really dislike it when a turing-complete language is used for configuration. It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Also I've been in projects where I had to debug the config multiple levels deep, tracking side-effects someone made in some constructor trying to DRY out the code. We already have these issues in the application itself. Lets not also do that in configurations.

crdrost 1y ago
This is what's nice about Pkl, you define a schema as a Pkl file, you define a value of that schema as a Pkl file that imports the schema, `pkl eval my file.pkl` will do the type check and output yaml for visual inspection or programmatic processing, but keeping it to one file per module means that I almost never obsessively D-R-Y my Pkl configs. Actually that's not the biggest benefit (which is tests for schemas) but it's nice to have the “.ts” file actually log the actual config as JSON and then the app consumes it as JSON, rather than importing the .ts file and all its dependencies and having weird things like “this configuration property expects a lambda.”
echelon 1y ago
That's why Starlark exists. You need something between JSON/YAML and Python/JavaScript. A config language makes the possibility space small. It also makes it deterministic for CI and repeatable builds. It also makes it parallelizable and cacheable. Don't use your language for config. People will abuse it. Use a config language like Starlark or RCL.
skydhash 1y ago
I still have to see a JS project where the config for each tool could not be something simple like `.toolrc`. We could have some markers to delineate plugins config. Instead, there’s a another software in the configuration of sample projects, instead of just using good code organization and sensible conventions.
your_fin 1y ago
> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read. I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them. I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'. The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX. > Side effects in constructors Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.

by nikeee 1y ago

crdrost 1y ago

This is what's nice about Pkl, you define a schema as a Pkl file, you define a value of that schema as a Pkl file that imports the schema, `pkl eval my file.pkl` will do the type check and output yaml for visual inspection or programmatic processing, but keeping it to one file per module means that I almost never obsessively D-R-Y my Pkl configs. Actually that's not the biggest benefit (which is tests for schemas) but it's nice to have the “.ts” file actually log the actual config as JSON and then the app consumes it as JSON, rather than importing the .ts file and all its dependencies and having weird things like “this configuration property expects a lambda.”

echelon 1y ago

That's why Starlark exists. You need something between JSON/YAML and Python/JavaScript. A config language makes the possibility space small. It also makes it deterministic for CI and repeatable builds. It also makes it parallelizable and cacheable. Don't use your language for config. People will abuse it. Use a config language like Starlark or RCL.

skydhash 1y ago

I still have to see a JS project where the config for each tool could not be something simple like `.toolrc`. We could have some markers to delineate plugins config. Instead, there’s a another software in the configuration of sample projects, instead of just using good code organization and sensible conventions.

your_fin 1y ago

> It almost always breaks every possibility to programmatically process or analyze the config. You can't just JSON.parse the file and check it. Counterpoint: 95% of config-readers are or could be checked in with all the config they ever read. I have yet to come across a programming language where it is easier to read + parse + type/structure validate a json/whatever file than it is to import a thing. Imports are also /much/ less fragile to e.g. the current working directory. And you get autocomplete! As for checks, you can use unit tests. And types, if you've got them. I try to frame these guys as "data values" rather than configuration though. People tend to have less funny ideas about making their data 'clean'. The only time where JSON.parse is actually easier is when you can't use a normal import. This boils down to when users write the data and have practical barriers to checking in to your source code. IME such cases are rare, and most are bad UX. > Side effects in constructors Putting such things in configuration files will not save you from people DRYing out the config files indirectly with effectful config processing logic. I recently spent the better part of a month ripping out one such chimera because changing the data model was intractable.