7 ms·

The first and the last ones, at least, are tradeoffs where TOML made the right decision for most users. Not being DRY is a good thing in a config file - it mak

The first and the last ones, at least, are tradeoffs where TOML made the right decision for most users. Not being DRY is a good thing in a config file - it makes it much easier to understand and work with just one section of the file (which is what you most often want to do), because the context information is right there without having to jump around and figure things out. And whatever the downsides of syntactic typing are, requiring a schema file to go along with your config file is far more of a downside; it's one more point of potential failure, another thing to maintain and sync up and keep in your head, and not worth it for most use cases. And that's the crux of it: it all depends on what you need from your markup language, what your use case is, today and through the lifetime of your project. "What's wrong with TOML" makes much less sense as a question than "What's wrong with TOML(/JSON/YAML/etc.) for _this project and its needs_".

hitchstory 3y ago
Hi, I'm the author of this piece. Thanks for your comments. >Not being DRY is a good thing in a config file - it makes it much easier to understand and work with just one section of the file (which is what you most often want to do), because the context information is right there without having to jump around and figure things out. If the contextual information is relevant that's true. However, syntactic noise of the form of lots of [s, ]s and equal signs isn't necessarily relevant. A YAML file can exhibit identical information with fewer characters and that makes the files easier to read and maintain - especially if they are information dense. >And whatever the downsides of syntactic typing are, requiring a schema file to go along with your config file is far more of a downside; it's one more point of potential failure Schemas aren't technically required by strictyaml provided you're happy mapping everything to a dict, list and string, but they're recommended because they make it much easier to prevent something from going wrong and it means you can directly use the types you were expecting. Schemas in config files are equivalent to static types that generate compiler errors in a program. If you can use them, it's an easy way to get your program to fail fast on invalid input and save on debugging time. If you don't have a schema and some invalid data gets put into your config file, instead of getting an error that says "didn't expect key "ip addresses" on line 14" you tend to get a really cryptic error a bit later on when your program tries to get a key from a dictionary that doesn't exist. This is an example of the principle of https://en.wikipedia.org/wiki/Fail-fast https://en.wikipedia.org/wiki/Fail-fast design.
- aeurielesn 3y ago
  I don't find TOML files easy to read/understand. Especially when I'm scrolling through a file, I encounter myself backtracking to understand again its structure.
  - taeric 3y ago
    Similarly, I don't find yaml easy to read/understand. XML had the curse of people trying to use every feature possible in most documents. And as much as I do prefer the "program" approach of emacs, I will make no defense of giant emacs config files, either.
    - masklinn 3y ago
      OTOH you can factorise and modularise an emacs config file. Sometimes an XML file if it uses xinclude (though that can be an issue in other ways). yaml? who knows. Whether and how (and the limitations) depends on whoever cooked up that pile.
    - marcosdumay 3y ago
      XML has the problem of too many features. If you personally decides to use them or not doesn't change the fact that whatever software reads it has to support them. XML parsing is also not a pure computation. That said, a XML-lite would quite probably be the best data encoding language one could create right now. It would still suck as a configuration language, as it's a very different problem.
      - networked 3y ago
        https://kdl.dev/ https://kdl.dev/ is an XML-lite configuration language with a pleasant syntax. It has a neat syntactic feature for commenting things out called "'slashdash' comments". An example from the spec: mynode /-"commented" "not commented" /-key="value" /-{ a b } A problem with a node-based design similar to XML compared to something that parses to nested lists and dictionaries is that you pretty much need a query API. Implementing it takes nontrivial extra work. This affects KDL implementations: KDL specifies a query language, but I think no Python KDL library has implemented it so far. It limits how useful KDL is in Python, despite there being multiple working parsers. Edit: Rephrased the second paragraph.
stared 3y ago
I beg to differ. If there are indentions, it is easy to fold long lists. For TOML, it takes mental effort to check whether items are from the same list or another. Additionally, in TOML, there are multiple ways to write a list (unlike in JSON), which makes it harder to parse - at least for me.
- taeric 3y ago
  The problem with that is that indentations within indentations are just obnoxious. It is far from uncommon to add an item at the wrong level in a large config file. Worst is when you have a large file that is showing several meaningful lines of indentation on one screen, where the roots of several of those levels is not visible.
nerdponx 3y ago
I think the primary limitation with TOML is the restriction that in-line tables cannot cross multiple lines. This is not done for technical reasons, it's an aesthetic choice on the part of the designer. It's analogous to forbidding comments in JSON. I love TOML and will continue to use it as my default choice for configuration files, because I think most applications simply do not need the power and flexibility of YAML, even if The outright safety problems are mostly resolved in YAML 1.2. But I do agree that the inability of the syntax to convey nested structure is a limitation and it definitely gets annoying in larger configuration files, such as pyproject.toml files that tend to accumulate in larger Python projects. I have considered just manually indenting nested table blocks, even though that would look pretty ugly and is decidedly non-standard.
- masklinn 3y ago
  > I think the primary limitation with TOML is the restriction that in-line tables cannot cross multiple lines. This is not done for technical reasons, it's an aesthetic choice on the part of the designer. I'm sure you'll be happy to know this is getting relaxed in toml 1.1, wherever that comes out (and the implementations adopt it): https://github.com/toml-lang/toml/issues/516 https://github.com/toml-lang/toml/issues/516 Though the difficulty will then be knowing whether a given piece of software uses 1.0 (and single-line tables) or 1.1 (and more flexible tables).
- eternityforest 3y ago
  YAML has a big problem in that you can't work with it in standard tools. Most every common GCedlanguage these days supports native JSONlike object, YAML can represent things outside of strings, lists, dicts, bools, numbers, and null. Lack of nested structure is a positive in some applications. Flat is better than nested. I've seen way too many config files where someone says "add foo=3" to the file and you can't even figure out where in the structure it goes. And worse, sometimes people reorganize things into options. They'll move all the stuff for one subcomponent into its own nested thing, and you can't configure it without knowing the full architecture. With flat stuff you get an obvious single way to represent any given config options. Maybe not the nicest way, but it's obvious and unique.
politelemon 3y ago
I don't even think this is about DRY and possibly misunderstands the DRY principle. DRY is about having a single authoritative source of information ("Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"). Repeating a portion of a key in a configuration file is not in violation, it would be if it were the value being repeated.
hot_gril 3y ago
> Not being DRY is a good thing in a config file Also unit test code is expected to be a lot less DRY.

hitchstory 3y ago

Hi, I'm the author of this piece. Thanks for your comments. >Not being DRY is a good thing in a config file - it makes it much easier to understand and work with just one section of the file (which is what you most often want to do), because the context information is right there without having to jump around and figure things out. If the contextual information is relevant that's true. However, syntactic noise of the form of lots of [s, ]s and equal signs isn't necessarily relevant. A YAML file can exhibit identical information with fewer characters and that makes the files easier to read and maintain - especially if they are information dense. >And whatever the downsides of syntactic typing are, requiring a schema file to go along with your config file is far more of a downside; it's one more point of potential failure Schemas aren't technically required by strictyaml provided you're happy mapping everything to a dict, list and string, but they're recommended because they make it much easier to prevent something from going wrong and it means you can directly use the types you were expecting. Schemas in config files are equivalent to static types that generate compiler errors in a program. If you can use them, it's an easy way to get your program to fail fast on invalid input and save on debugging time. If you don't have a schema and some invalid data gets put into your config file, instead of getting an error that says "didn't expect key "ip addresses" on line 14" you tend to get a really cryptic error a bit later on when your program tries to get a key from a dictionary that doesn't exist. This is an example of the principle of https://en.wikipedia.org/wiki/Fail-fast https://en.wikipedia.org/wiki/Fail-fast design.

aeurielesn 3y ago
I don't find TOML files easy to read/understand. Especially when I'm scrolling through a file, I encounter myself backtracking to understand again its structure.
- taeric 3y ago
  Similarly, I don't find yaml easy to read/understand. XML had the curse of people trying to use every feature possible in most documents. And as much as I do prefer the "program" approach of emacs, I will make no defense of giant emacs config files, either.
  - masklinn 3y ago
    OTOH you can factorise and modularise an emacs config file. Sometimes an XML file if it uses xinclude (though that can be an issue in other ways). yaml? who knows. Whether and how (and the limitations) depends on whoever cooked up that pile.
  - marcosdumay 3y ago
    XML has the problem of too many features. If you personally decides to use them or not doesn't change the fact that whatever software reads it has to support them. XML parsing is also not a pure computation. That said, a XML-lite would quite probably be the best data encoding language one could create right now. It would still suck as a configuration language, as it's a very different problem.
    - networked 3y ago
      https://kdl.dev/ https://kdl.dev/ is an XML-lite configuration language with a pleasant syntax. It has a neat syntactic feature for commenting things out called "'slashdash' comments". An example from the spec: mynode /-"commented" "not commented" /-key="value" /-{ a b } A problem with a node-based design similar to XML compared to something that parses to nested lists and dictionaries is that you pretty much need a query API. Implementing it takes nontrivial extra work. This affects KDL implementations: KDL specifies a query language, but I think no Python KDL library has implemented it so far. It limits how useful KDL is in Python, despite there being multiple working parsers. Edit: Rephrased the second paragraph.

stared 3y ago

I beg to differ. If there are indentions, it is easy to fold long lists. For TOML, it takes mental effort to check whether items are from the same list or another. Additionally, in TOML, there are multiple ways to write a list (unlike in JSON), which makes it harder to parse - at least for me.

taeric 3y ago
The problem with that is that indentations within indentations are just obnoxious. It is far from uncommon to add an item at the wrong level in a large config file. Worst is when you have a large file that is showing several meaningful lines of indentation on one screen, where the roots of several of those levels is not visible.

nerdponx 3y ago

I think the primary limitation with TOML is the restriction that in-line tables cannot cross multiple lines. This is not done for technical reasons, it's an aesthetic choice on the part of the designer. It's analogous to forbidding comments in JSON. I love TOML and will continue to use it as my default choice for configuration files, because I think most applications simply do not need the power and flexibility of YAML, even if The outright safety problems are mostly resolved in YAML 1.2. But I do agree that the inability of the syntax to convey nested structure is a limitation and it definitely gets annoying in larger configuration files, such as pyproject.toml files that tend to accumulate in larger Python projects. I have considered just manually indenting nested table blocks, even though that would look pretty ugly and is decidedly non-standard.

masklinn 3y ago
> I think the primary limitation with TOML is the restriction that in-line tables cannot cross multiple lines. This is not done for technical reasons, it's an aesthetic choice on the part of the designer. I'm sure you'll be happy to know this is getting relaxed in toml 1.1, wherever that comes out (and the implementations adopt it): https://github.com/toml-lang/toml/issues/516 https://github.com/toml-lang/toml/issues/516 Though the difficulty will then be knowing whether a given piece of software uses 1.0 (and single-line tables) or 1.1 (and more flexible tables).
eternityforest 3y ago
YAML has a big problem in that you can't work with it in standard tools. Most every common GCedlanguage these days supports native JSONlike object, YAML can represent things outside of strings, lists, dicts, bools, numbers, and null. Lack of nested structure is a positive in some applications. Flat is better than nested. I've seen way too many config files where someone says "add foo=3" to the file and you can't even figure out where in the structure it goes. And worse, sometimes people reorganize things into options. They'll move all the stuff for one subcomponent into its own nested thing, and you can't configure it without knowing the full architecture. With flat stuff you get an obvious single way to represent any given config options. Maybe not the nicest way, but it's obvious and unique.

politelemon 3y ago

I don't even think this is about DRY and possibly misunderstands the DRY principle. DRY is about having a single authoritative source of information ("Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"). Repeating a portion of a key in a configuration file is not in violation, it would be if it were the value being repeated.

hot_gril 3y ago

> Not being DRY is a good thing in a config file Also unit test code is expected to be a lot less DRY.