4 ms·

It's funny how little developers think about how to do configuration right. It's just a bunch of keys and values, stored in some file, or generated by some cod

by valty 3y ago

It's funny how little developers think about how to do configuration right. It's just a bunch of keys and values, stored in some file, or generated by some code. But its actually the whole ball game. It's what programming is. Everything is configuration. Every function parameter is a kind of configuration. And all the configuration in external files inevitably ends up as a function parameter in some way. The problem is the plain-text representation of code. Declarative configuration files seem nice because you can see everything in one place. If you do your configuration programmatically, it is hard to find the correct place to change something. If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought. Now extend this concept to all of programming. Imagine being able to see every piece of code that depends upon a single configuration value, and any transformations of it. Also, most configuration is probably better placed into a central database because it is relational/graph-like. Different configuration values relate to one another. So we should be looking at configuration in a database/graph editor. Once you unchain yourself from plain-text, things start to become a lot simpler...of course the language capabilities I mentioned above still need to become a thing.

Syntonicles 3y ago
This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together. I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a no-go, in addition to the disadvantage you mentioned. My next thought was that there should be a better way to show the configuration, and allow that configuration to be modified. I was thinking maybe some sort of visual UI which where the user can navigate a representation of the final product, select a part and modify a parameter that way. Is that along the lines of your suggestion? If not will you please expand a little? Configuration is the absolute core of this application.
- valty 3y ago
  Sounds like you need an SQL database. You could use SQLite. Then provide a GUI to modify that database. You could add a bunch of constraints in the database too to ensure the config is correct. Usually when there is plain-text files though, it's because they want it that way. It's easier to edit a text file sometimes than rows in a database. Cut/copy/paste/duplicate files and text. Simple textual version control.
  - Syntonicles 3y ago
    Sure, I agree - I'm proposing JSON as an intermediate step toward a well-defined data-model since the thousands of copied config files have evolved over time, so the data-model is a smear of backward-compatibility hacks. What I was trying to do is get you to explain what you mean by this: > If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. [...] But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.
    - valty 3y ago
      This is only relevant if you allow code to define config. If you use conditionals and loops to create config, and then view the final json, it quickly becomes annoying when you know the thing you want to change in the final json, but have to trace backwards through the code to figure out where to change it. So programmatic configs only work if you have this "value tracing" capability. Which nothing really does.

by valty 3y ago

Syntonicles 3y ago

This is something I'm trying really hard to do with a client. They have a bunch of 1500+ line "config" files for products, which are then used to make technical drawings and production files. The configs attempt to use naming scheme to group related variables together. I want to migrate to an actual nested data-structure using (maybe) JSON - and these engineers absolutely will not write code, so config-as-code is a no-go, in addition to the disadvantage you mentioned. My next thought was that there should be a better way to show the configuration, and allow that configuration to be modified. I was thinking maybe some sort of visual UI which where the user can navigate a representation of the final product, select a part and modify a parameter that way. Is that along the lines of your suggestion? If not will you please expand a little? Configuration is the absolute core of this application.

valty 3y ago
Sounds like you need an SQL database. You could use SQLite. Then provide a GUI to modify that database. You could add a bunch of constraints in the database too to ensure the config is correct. Usually when there is plain-text files though, it's because they want it that way. It's easier to edit a text file sometimes than rows in a database. Cut/copy/paste/duplicate files and text. Simple textual version control.
- Syntonicles 3y ago
  Sure, I agree - I'm proposing JSON as an intermediate step toward a well-defined data-model since the thousands of copied config files have evolved over time, so the data-model is a smear of backward-compatibility hacks. What I was trying to do is get you to explain what you mean by this: > If our code ran in real-time to show us a representation of the final configuration, and we could trace how each final configuration value was generated, then it wouldn't be a problem. [...] But no systems are designed with this capability, even though it is quite trivial to do. Configuration is always an after-thought.
  - valty 3y ago
    This is only relevant if you allow code to define config. If you use conditionals and loops to create config, and then view the final json, it quickly becomes annoying when you know the thing you want to change in the final json, but have to trace backwards through the code to figure out where to change it. So programmatic configs only work if you have this "value tracing" capability. Which nothing really does.