Although I do feel like there is a case to be made that if you need a Turing complete configuration language then in most cases you failed your users by pushing too many decisions on to them instead of deciding on sensible defaults.
And if you are dealing with one of the rare cases where Turing complete configuration is desirable then maybe use Lua or something like that instead.
I'm not defending YAML. YAML is terrible. It's even worse with logic and/or templates (looking at you, Ansible). Toml is certainly better but I'm still baffled as to why we don't have a "better YAML". YAML could almost be okay.
This is why I like INI. It doesn't have these problems, because it doesn't try to wrangle the notion of nested objects (or lists) in the first place. The lack of a formal spec is a problem, sure, but it such a basic format that it's kind of self-explanatory.
When the problem is TOML not supporting easy nesting, a solution of "Don't nest." works just as well in TOML as it does in ini. It's not really an advantage of ini. Especially when a big factor in TOML not making it easy is that TOML uses the same kind of [section]\nkey=value formatting that ini does!
Toml has some hairy bits. Lists of objects, lists of lists of objects, objects of lists of objects. Complex objects with top level fields...
Yep,
Although I do feel like there is a case to be made that if you need a Turing complete configuration language then in most cases you failed your users by pushing too many decisions on to them instead of deciding on sensible defaults.
And if you are dealing with one of the rare cases where Turing complete configuration is desirable then maybe use Lua or something like that instead.
I'm not defending YAML. YAML is terrible. It's even worse with logic and/or templates (looking at you, Ansible). Toml is certainly better but I'm still baffled as to why we don't have a "better YAML". YAML could almost be okay.
22 replies →
Even if you have sensible defaults don't you still need to be able to parse configured changes?
1 reply →
I understand the pragmatic reasons for it being the way it is, but I still wish TOML didn't require all strings to be quoted.
This is why I like INI. It doesn't have these problems, because it doesn't try to wrangle the notion of nested objects (or lists) in the first place. The lack of a formal spec is a problem, sure, but it such a basic format that it's kind of self-explanatory.
When the problem is TOML not supporting easy nesting, a solution of "Don't nest." works just as well in TOML as it does in ini. It's not really an advantage of ini. Especially when a big factor in TOML not making it easy is that TOML uses the same kind of [section]\nkey=value formatting that ini does!
You can use toml as a better ini by limiting yourself to the key / value schema. It still superior because:
- it has a spec
- it has other types than strings
- you can always decide you actually need nested data, and add them later
3 replies →
... lack of a hex float representation ...