← Back to context

Comment by dnautics

3 years ago

Toml has some hairy bits. Lists of objects, lists of lists of objects, objects of lists of objects. Complex objects with top level fields...

34 comments

dnautics

Reply
chillfox  3 years ago

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.

  • dnautics  3 years ago

    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.

    • chillfox  3 years ago

      Yeah, I think it's because nobody sat down and methodically created it.

      People create config languages that work for their use case and then it is just a happy accident if it works for other things.

      I don't think anyone has put serous effort into designing a configuration language. And by that I mean collect use cases, study how other config languages does things, make drafts, and test them. etc...

      13 replies →

    • chillfox  3 years ago

      About Ansible, I think it gained it's success partially due to YAML.

      Ansible is worse than Puppet and CFEngine in many ways, but it is superior in the user interface.

      It managed to not only be a config management solution, but provide a universal config language that most apps could be configured with. So for a lot of use cases, if you know Anisible/YAML then you don't have to learn a new configuration language on top of learning a new application.

      3 replies →

    • vitiral  3 years ago

      I'm curious what your thoughts are on a config language I'm working on.

      GitHub.com/vitiral/zoa

      It has both binary and textual representation (with the first byte being able to distinguish them), and the syntax is clean enough I'm planning on extending it into a markup language as well.

  • pc86  3 years ago

    Even if you have sensible defaults don't you still need to be able to parse configured changes?

    • chillfox  3 years ago

      Not always, sometimes all other options are just wrong. Or you can auto detect the correct setting.

mikepurvis  3 years ago

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.

ryukoposting  3 years ago

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.

  • Dylan16807  3 years ago

    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!

  • BiteCode_dev  3 years ago

    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

    • ryukoposting  3 years ago

      I wrote an INI parser that has numerical, boolean, timestamp, MAC address, and IP address types ;) "advantages" of not having a spec!

      Seriously: for application-specific config files, the lack of a formal spec can be kind of a nice thing. You can design your parser to the exact needs of your program, with data types that makes sense for your use case. Throw together a formal grammar for use in regression testing, and you're all set.

      Obviously a formal spec is essential for data interchange, but that's why JSON exists. To me, YAML is in a gray area that doesn't need to exist. The same thing goes for TOML, but to a far lesser extent.