The author does not seem to appreciate separating tokenization from interpretation. Can you right a (choose your data format of choice) document that is valid i

The author does not seem to appreciate separating tokenization from interpretation. Can you right a (choose your data format of choice) document that is valid in (your data format of choice) and not valid config for your application? Absolutely! Can you right an arbitrarily specked INI file that is both invalid structurally and not valid? Even more so! Choosing a standardized data format gives you a constellation of tools for managing, generating, querying, and validating data that you don’t need to write in an application. I’m not sure if TOML libraries support it, but the Ion libraries, for example, allow you to see the next data type in code and adjust accordingly. If you want to accept a symbol, string, or array of values, the application can choose to do that. Oh, and you can write a formal schema with things like enumeration values that users and code can use to validate a document. So if you’re in custom INI land, that’s yet another tool you need to write on top of everything else. If I didn’t want to pull in a dependency, I might write a quick and dirty INI parser, knowing there are likely bugs, corner cases, and all kinds of potential future issues that the extra code entails. If I’m taking on a dependency, I’d probably choose a well defined, human and machine readable/writable format that has schema support. Then I’d write a schema and point people (operators and programmers) to it for reference, not the code implementing the parser.