[HN Gopher] The 5 levels of configuration languages
       ___________________________________________________________________
        
       The 5 levels of configuration languages
        
       Author : kaycebasques
       Score  : 16 points
       Date   : 2025-04-12 20:00 UTC (3 hours ago)
        
 (HTM) web link (beza1e1.tuxen.de)
 (TXT) w3m dump (beza1e1.tuxen.de)
        
       | kristopolous wrote:
       | The distance between 3 and 4 are wider and have more members.
       | Take CSS for example.
        
         | qznc wrote:
         | CSS is at least level 4. You can even argue for level 5, i.e.
         | Turing-complete:
         | https://stackoverflow.com/questions/2497146/is-css-turing-co...
        
           | kristopolous wrote:
           | Level 4 is turing complete.
           | 
           | There's two parts that I was talking about. Things that are
           | not quite that and the fact that configuration can have that
           | capability in a fairly useless context.
           | 
           | When I'm dealing with personal things or stuff that few
           | people use I will often make the configuration just something
           | I eval/source.
           | 
           | So it in theory has the same functionality as the underlying
           | programming language, but in practice you're just supposed to
           | use it like an INI.
           | 
           | Here's a fairly large personal project where I use that
           | 
           | https://github.com/kristopolous/music-explorer
           | 
           | It actually allowed to change the behavior pending on whether
           | I'm running my program from my office or home. So invoking
           | the full Fidelity of the underlying language actually has its
           | benefits at times.
           | 
           | I know security people will get in a tiffy over this but
           | really, It's personal software I wrote myself in a managing
           | myself. gitconfig ostensibly has the same issues.
        
       | ajb wrote:
       | I'm not convinced by reducing this to a single dimension. There
       | are differences in both 'what can be expressed' and 'what
       | validation can be done' which are somewhat independent of each
       | other
        
       | sgeisenh wrote:
       | > Don't waste time on discussions within a level.
       | 
       | I disagree with this. YAML has too many footguns (boolean
       | conversions being the first among them) not to mention it is a
       | superset of JSON. Plain old JSON or TOML are much simpler.
        
       | rdtsc wrote:
       | That's a good breakdown.
       | 
       | In practice configuration systems that reach level 4 or 5 start
       | to look complex and the whole thing ends up with a new rewrite
       | into a level 2 or 3. After a while it expands, because it needs
       | comments, include files, templating, for loops, etc., until it
       | becomes a total mess and gets thrown out and we cycle back to
       | level 3.
        
       | susam wrote:
       | About 20 or so years ago, I have come across a configuration
       | pattern that could be arguably called "Level 0". It was
       | configuration by file existence. The file itself would be
       | typically empty. So no parsing, syntax, or schema involved. For
       | example, if the file /opt/foo/foo.txt exists, the software does
       | one thing but if it is missing the software does another thing.
       | So effectively, the existence of the file serves as a boolean
       | configuration flag.
        
         | delichon wrote:
         | So what comes after Level 5: full programming language? How
         | about                 Level 6: agent continuously optimizes
         | config values according to simulations from specs and latest
         | data            Level 7: agent continuously optimizes agent
         | algorithm
        
       | behnamoh wrote:
       | Lisp code is represented in the same data structure it
       | manipulates. This homoiconicity makes Lisp code be a great config
       | data especially in a Lisp program. In comparison, you can't
       | represent JS code in JSON.
        
       | 18172828286177 wrote:
       | > Don't waste time on discussions within a level. For example,
       | JSON and YAML both have their problems and pitfalls but both are
       | probably good enough.
       | 
       | Disagree. YAML is considerably easier to work with than JSON, and
       | it's worth dying on that hill.
        
         | MOARDONGZPLZ wrote:
         | I love that there is one comment saying JSON is better, and
         | then yours saying YAML is better.
        
       ___________________________________________________________________
       (page generated 2025-04-12 23:00 UTC)