5 ms·

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 wi

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.
      - marcosdumay 3y ago
        That language is very interesting, thank you. But I do disagree on the work. A node-based language parses into a sequence of (name, node_type, data) tuples. What is just as easy to travel as the (name, data) from the data map ones. The thing is, a query language is much more useful for them than for a data map, so it's worthwhile to implement one. (There's probably some cultural aspect here too.)
camgunz 3y ago
> However, syntactic noise of the form of lots of [s, ]s and equal signs isn't necessarily relevant. I don't know that ': ' is any better than ' = '. I get being opinionated about it but this feels squarely in the realm of the subjective to me. Further, adding an errant '-' and accidentally creating another object is real common in YAML, which is something you can't do with TOML's lists. I think this washes out, tbh.
- hitchstory 3y ago
  I actually tried to demonstrate this with numbers a while back. I tried taking a few random JSON files as a control and representing them with StrictYAML and TOML and the TOML varied from 30% to 100% longer. There is an element of opinion here, but there is no question that equivalent TOML files are longer, and most of that is syntax. It's much more pronounced when you have more than one or two levels of nesting. With 4 or 5 levels of object nesting TOML files grow huge, whereas YAML is still fine. >Further, adding an errant '-' and accidentally creating another object is real common in YAML Yep, this is one of the things that type safety helps with though. Similarly it's quite easy to mess up an indent in YAML, but a schema can catch that stuff.
  - marcosdumay 3y ago
    > It's much more pronounced when you have more than one or two levels of nesting. Yes. That's a clear indication that either you configuration type structure is badly designed, or that you aren't trying to create a configuration type and should use some data encoding or programing language that fits your problem better. I guarantee you the people using your software will curse you every time they try to edit a YAML file with more than 3 levels of nesting.
    - camgunz 3y ago
      I confess I feel strongly in opposite directions on this. I'm pretty biased against YAML: I think it's way way too complex, and its "declarative" nature and broad feature set essentially make it a complexity magnet. I've seen hellish YAML files, and it's also pretty common to combine them with Jinja (or w/e) for extra hellsauce. But it's declarative, which is really cool! What else would you realistically use for like, AWS infra? The JSON version is so much worse. Using Python or whatever is its own can of worms. This is the kind of thing that stuff like CUE and Dhall are aiming at, and I welcome it. It feels like they're the way out here.
AndyKluger 3y ago
Thanks for your work! I first encountered strictyaml years ago and have used it, happily. I especially appreciate that you made clear arguments for what ought to be excluded from a configuration format itself, and how proper validation ultimately requires real code anyway. I was always disappointed however that your project didn't amount to a formal specification (at least at the time, unsure if that's changed). More recently I came to know and love NestedText, which seems very close to what a strictyaml spec could be/have been. I'm curious if you've engaged with that project/format, and what you think of it.
- hitchstory 3y ago
  >I was always disappointed however that your project didn't amount to a formal specification (at least at the time, unsure if that's changed). I would dearly love to do this. I would ideally like to work with somebody who can help me though because it's a lot of work and I struggle to find the time.
  - AndyKluger 3y ago
    NestedText seems very close to what a strictyaml spec could be/have been. I'm curious if you've engaged with that project/format, and what you think of it.
dwattttt 3y ago
> 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. I don't think this is a particularly good yardstick. Code without comments is shorter than code with comments, but I wouldn't call comment-less code easier to read; the more information dense, the worse, really.
Hendrikto 3y ago
> A YAML file can exhibit identical information with fewer characters and that makes the files easier to read and maintain According to that logic, binary files would be easiest to maintain and read, which is obviously bogus.
slowmovintarget 3y ago
Doesn't YAML have the unfortunate issue of ambiguity in the variety of parsing and versions? (Edit: I see you're advocating for a new subset... never mind. :) ) If you want a "language" for expressing data (like configuration data), you might be interesting in having a look at EDN. https://github.com/edn-format/edn https://github.com/edn-format/edn

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.
    - marcosdumay 3y ago
      That language is very interesting, thank you. But I do disagree on the work. A node-based language parses into a sequence of (name, node_type, data) tuples. What is just as easy to travel as the (name, data) from the data map ones. The thing is, a query language is much more useful for them than for a data map, so it's worthwhile to implement one. (There's probably some cultural aspect here too.)

camgunz 3y ago

> However, syntactic noise of the form of lots of [s, ]s and equal signs isn't necessarily relevant. I don't know that ': ' is any better than ' = '. I get being opinionated about it but this feels squarely in the realm of the subjective to me. Further, adding an errant '-' and accidentally creating another object is real common in YAML, which is something you can't do with TOML's lists. I think this washes out, tbh.

hitchstory 3y ago
I actually tried to demonstrate this with numbers a while back. I tried taking a few random JSON files as a control and representing them with StrictYAML and TOML and the TOML varied from 30% to 100% longer. There is an element of opinion here, but there is no question that equivalent TOML files are longer, and most of that is syntax. It's much more pronounced when you have more than one or two levels of nesting. With 4 or 5 levels of object nesting TOML files grow huge, whereas YAML is still fine. >Further, adding an errant '-' and accidentally creating another object is real common in YAML Yep, this is one of the things that type safety helps with though. Similarly it's quite easy to mess up an indent in YAML, but a schema can catch that stuff.
- marcosdumay 3y ago
  > It's much more pronounced when you have more than one or two levels of nesting. Yes. That's a clear indication that either you configuration type structure is badly designed, or that you aren't trying to create a configuration type and should use some data encoding or programing language that fits your problem better. I guarantee you the people using your software will curse you every time they try to edit a YAML file with more than 3 levels of nesting.
  - camgunz 3y ago
    I confess I feel strongly in opposite directions on this. I'm pretty biased against YAML: I think it's way way too complex, and its "declarative" nature and broad feature set essentially make it a complexity magnet. I've seen hellish YAML files, and it's also pretty common to combine them with Jinja (or w/e) for extra hellsauce. But it's declarative, which is really cool! What else would you realistically use for like, AWS infra? The JSON version is so much worse. Using Python or whatever is its own can of worms. This is the kind of thing that stuff like CUE and Dhall are aiming at, and I welcome it. It feels like they're the way out here.

AndyKluger 3y ago

Thanks for your work! I first encountered strictyaml years ago and have used it, happily. I especially appreciate that you made clear arguments for what ought to be excluded from a configuration format itself, and how proper validation ultimately requires real code anyway. I was always disappointed however that your project didn't amount to a formal specification (at least at the time, unsure if that's changed). More recently I came to know and love NestedText, which seems very close to what a strictyaml spec could be/have been. I'm curious if you've engaged with that project/format, and what you think of it.

hitchstory 3y ago
>I was always disappointed however that your project didn't amount to a formal specification (at least at the time, unsure if that's changed). I would dearly love to do this. I would ideally like to work with somebody who can help me though because it's a lot of work and I struggle to find the time.
- AndyKluger 3y ago
  NestedText seems very close to what a strictyaml spec could be/have been. I'm curious if you've engaged with that project/format, and what you think of it.

dwattttt 3y ago

> 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. I don't think this is a particularly good yardstick. Code without comments is shorter than code with comments, but I wouldn't call comment-less code easier to read; the more information dense, the worse, really.

Hendrikto 3y ago

> A YAML file can exhibit identical information with fewer characters and that makes the files easier to read and maintain According to that logic, binary files would be easiest to maintain and read, which is obviously bogus.

slowmovintarget 3y ago

Doesn't YAML have the unfortunate issue of ambiguity in the variety of parsing and versions? (Edit: I see you're advocating for a new subset... never mind. :) ) If you want a "language" for expressing data (like configuration data), you might be interesting in having a look at EDN. https://github.com/edn-format/edn https://github.com/edn-format/edn