4 ms·

And what is the argument?

by sly010 8y ago

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.

And what is the argument?

by sly010 8y ago

And what is the argument?

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.