5 ms·

But what do you do when dealing with large numbers across platforms? Represent them as a string? I have recently been moving to toml.

revskill 8y ago
Consider using all config files as `app.config.js` , you can just return a JS object and done.
- adwn 8y ago
  > Consider using all config files as `app.config.js` , you can just return a JS object and done. It's kind of sad that you seem to think that JavaScript is the only relevant language in existence.
  - revskill 8y ago
    It's because my projects are universal application, that's why Javascript. But JS is not the only choice. What i mean is, we want a programmable config file, not "static one"
    - sly010 8y ago
      This topic interests me. I am very interested to hear what the specific issues are with "non programmable" config files in your case. Generally I find that people often choose config languages because of syntax preference, where in reality they should be thinking if what they are trying to express is data or behavior? Ansible should have been just python. Yaml makes for an ugly programming language. Whereas python setup.py files should have been anything but python. It's a terrible source of metadata. There are cases of course where the distinction is not that obvious. Is your nginx config data or a program/behavior? How about your CI config?
      - revskill 8y ago
        Some common use cases: - Compile config.js into config.json or config.yaml, use that config.js as an intermediate format to compile to real config. - Environment variables, or require 'other-module.js'
      - giornogiovanna 8y ago
        You've probably already seen this, but https://www.youtube.com/watch?v=0pX7-AG52BU https://www.youtube.com/watch?v=0pX7-AG52BU (a talk on configuration at Jane Street) goes over some of these issues at depth.
- 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.

revskill 8y ago

Consider using all config files as `app.config.js` , you can just return a JS object and done.

adwn 8y ago
> Consider using all config files as `app.config.js` , you can just return a JS object and done. It's kind of sad that you seem to think that JavaScript is the only relevant language in existence.
- revskill 8y ago
  It's because my projects are universal application, that's why Javascript. But JS is not the only choice. What i mean is, we want a programmable config file, not "static one"
  - sly010 8y ago
    This topic interests me. I am very interested to hear what the specific issues are with "non programmable" config files in your case. Generally I find that people often choose config languages because of syntax preference, where in reality they should be thinking if what they are trying to express is data or behavior? Ansible should have been just python. Yaml makes for an ugly programming language. Whereas python setup.py files should have been anything but python. It's a terrible source of metadata. There are cases of course where the distinction is not that obvious. Is your nginx config data or a program/behavior? How about your CI config?
    - revskill 8y ago
      Some common use cases: - Compile config.js into config.json or config.yaml, use that config.js as an intermediate format to compile to real config. - Environment variables, or require 'other-module.js'
    - giornogiovanna 8y ago
      You've probably already seen this, but https://www.youtube.com/watch?v=0pX7-AG52BU https://www.youtube.com/watch?v=0pX7-AG52BU (a talk on configuration at Jane Street) goes over some of these issues at depth.
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.