4 ms·

There is an argument to be made for doing config in the language of your application. It's a pattern I've seen in codebases using JS, Elixir, Scala, Haskell, an

by strken 8y ago

There is an argument to be made for doing config in the language of your application. It's a pattern I've seen in codebases using JS, Elixir, Scala, Haskell, and even C if DWM counts.

sly010 8y ago
And what is the argument?
- ineedasername 8y ago
  Maybe that future maintainers/inheritors of the application would thereby be defacto knowledgeable in the config language as well?
- strken 8y ago
  First, your config isn't a static file that you read wherever you access it, but a library that defines how to load config, and if you treat it as a static file you'll potentially have trouble adapting your code if you want to load config from environmental variables or centralised config management tools. Second, if you load your config from a different language like JSON, you miss out on the benefits of your first language, like static typing. Static typing gives you nice things like build-time failures for invalid config and integrated configuration autocompletion in IDEs and editors. Third, you can do things like merging environment-specific configs into a base config or programmatically filling in an array of values explicitly and in a way that's easy to follow. If you're using Fibonacci backoff, you can write "cfg.backoffRetryTimings = fibonacci(100)" instead of listing 100 numbers.
  - sly010 8y ago
    > want to load config from environmental variables or centralized config management tools. I am not sure I understand this, I have a feeling you are mixing "configuration" with "loading the configuration" here which is a slippery slope. > you miss out on the benefits of your first language, like static typing Again, you are confusing configuration with writing your application. You have a point here if you are your applications only user (e.g. server apps) and you have to recompile anyway. > Third, you can do things like merging environment-specific configs into a base config Again, I am not sure if your config file is the place to do that. I would argue that your configuration should be different in different environments instead of having a smart configuration that recognizes the environment and does a bunch of different things. > or programmatically filling in an array of values explicitly and in a way that's easy to follow. This is also a good point and is definitely a place where JSON falls short. Good stuff.

by strken 8y ago

There is an argument to be made for doing config in the language of your application. It's a pattern I've seen in codebases using JS, Elixir, Scala, Haskell, and even C if DWM counts.

sly010 8y ago

And what is the argument?

ineedasername 8y ago
Maybe that future maintainers/inheritors of the application would thereby be defacto knowledgeable in the config language as well?
strken 8y ago
First, your config isn't a static file that you read wherever you access it, but a library that defines how to load config, and if you treat it as a static file you'll potentially have trouble adapting your code if you want to load config from environmental variables or centralised config management tools. Second, if you load your config from a different language like JSON, you miss out on the benefits of your first language, like static typing. Static typing gives you nice things like build-time failures for invalid config and integrated configuration autocompletion in IDEs and editors. Third, you can do things like merging environment-specific configs into a base config or programmatically filling in an array of values explicitly and in a way that's easy to follow. If you're using Fibonacci backoff, you can write "cfg.backoffRetryTimings = fibonacci(100)" instead of listing 100 numbers.
- sly010 8y ago
  > want to load config from environmental variables or centralized config management tools. I am not sure I understand this, I have a feeling you are mixing "configuration" with "loading the configuration" here which is a slippery slope. > you miss out on the benefits of your first language, like static typing Again, you are confusing configuration with writing your application. You have a point here if you are your applications only user (e.g. server apps) and you have to recompile anyway. > Third, you can do things like merging environment-specific configs into a base config Again, I am not sure if your config file is the place to do that. I would argue that your configuration should be different in different environments instead of having a smart configuration that recognizes the environment and does a bunch of different things. > or programmatically filling in an array of values explicitly and in a way that's easy to follow. This is also a good point and is definitely a place where JSON falls short. Good stuff.