Comment by Syntonicles | Hacker News Reader

Comment by Syntonicles | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

Reply on news.ycombinator.com