4 ms·

> Statically typed programming languages are catching on so why don’t we extend this typing to our config files? Because I simply don't want to expend the same

> Statically typed programming languages are catching on so why don’t we extend this typing to our config files? Because I simply don't want to expend the same amount of cognitive load to read config files as I do for code. Yes, yaml has some minor ambiguities. These are easily solved. To use the example from the article: countries: - ca - "no" - us There, done. The problem was solved with 2 extra characters and remembering the fact that `no` is special in yaml. Comparing that to the amount of typing I have to do to define a scheme, the syntax of which I have to learn, which I also have to read or remember and keep in mind every time I read the config, I take the 2 extra double-quotes. And, speaking of statically typed languages: This problem would be caught immediately anyway if the config is read into static types.

kevincox 5y ago
> Comparing that to the amount of typing I have to do to define a scheme From my use case of config files the code that is reading them knows the type anyways. So for a setup like Rust+serde there is no overhead to set this up. > This problem would be caught immediately anyway if the config is read into static types. That is true, but it still breaks you out of your flow. You get a confusing error, it probably doesn't tell you the exact line number and you need to look over your changes. If you changed a lot of places in the file it may be easy to miss that adding `no` to a list was the mistake. Because problems like that are easy to understand in retrospect, but if you keep reading "no" as "Norway" it is easy to look straight at this mistake and think it is fine before hunting elsewhere in the file. I think you are right. It is still unclear if the cognitive overhead when writing the file is worth it, but from my point of view the upsides are much more valuable then you make them appear to be.
andrewzah 5y ago
"There, done." Except, we're not done. YAML has multiple footguns like this, which I have to remember, forever. And anyone who works with YAML. It's unintuitive and confusing, and costs space in my brain that I really should be using for more important things. Not to mention that if you -don't- know about these ahead of time, debugging them can be confusing. A type system is marginally more work for decreased cognitive load and eliminating stupid, idiotic bugs that nobody should have to waste their time tracking down. With IDE integration, the cost is pretty much negligible other than learning the syntax, which, c'mon, is not difficult and we're being paid to do it. There are even tools like Dhall [0] that auto-generate yaml for us. [0]: https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang
- TrainedMonkey 5y ago
  Would most of the footguns be solved by quoting all of the strings? e.g: "countries": - "ca" - "no" - "us"
  - kevincox 5y ago
    Yes, but now you are losing a lot of the clean syntax that causes most people to use YAML in the first place. There is a reason that most people don't write YAML like JSON with trailing commas and comments, it is nice to cut most of this noise.
    - meowface 5y ago
      You can also use a stricter subset of YAML that removes things like the "no" footgun. Plenty of such strict parsers exist across languages. Maybe it's no longer technically YAML at that point, but you get all the nice parts of YAML without having to revamp everything with static typing.
- Spivak 5y ago
  So yes it’s a footgun but it makes some sense. Most people wouldn’t really complain about true not being equivalent to “true” or 100 not keeping it “100”. People just aren’t used to yes/no being reserved words. Ruby’s klass is a funny workaround to this. enable_feature: yes Is totally natural. Nobody reads the spec though. If you’re outputting YAML documents with string builders you’re headed for ruin no matter what. You don’t need Dhall, you need yaml.dump which handles the types too.
CBLT 5y ago
I agree that the problem is one of quicker feedback - the dev cycle should involve a program checking the yaml correctness (using types or otherwise) straight away and giving a useful error message. Too often I've seen incorrect yaml checked into git that fails with a cryptic error when deploying the application. The strength of types, in my opinion, is composability. Most config files I've seen have ultimately pulled in input from another source and used that to create their output. Types would allow the configuration to be checked for correctness even in the face of unknowns.

kevincox 5y ago

> Comparing that to the amount of typing I have to do to define a scheme From my use case of config files the code that is reading them knows the type anyways. So for a setup like Rust+serde there is no overhead to set this up. > This problem would be caught immediately anyway if the config is read into static types. That is true, but it still breaks you out of your flow. You get a confusing error, it probably doesn't tell you the exact line number and you need to look over your changes. If you changed a lot of places in the file it may be easy to miss that adding `no` to a list was the mistake. Because problems like that are easy to understand in retrospect, but if you keep reading "no" as "Norway" it is easy to look straight at this mistake and think it is fine before hunting elsewhere in the file. I think you are right. It is still unclear if the cognitive overhead when writing the file is worth it, but from my point of view the upsides are much more valuable then you make them appear to be.

andrewzah 5y ago

"There, done." Except, we're not done. YAML has multiple footguns like this, which I have to remember, forever. And anyone who works with YAML. It's unintuitive and confusing, and costs space in my brain that I really should be using for more important things. Not to mention that if you -don't- know about these ahead of time, debugging them can be confusing. A type system is marginally more work for decreased cognitive load and eliminating stupid, idiotic bugs that nobody should have to waste their time tracking down. With IDE integration, the cost is pretty much negligible other than learning the syntax, which, c'mon, is not difficult and we're being paid to do it. There are even tools like Dhall [0] that auto-generate yaml for us. [0]: https://github.com/dhall-lang/dhall-lang https://github.com/dhall-lang/dhall-lang

TrainedMonkey 5y ago
Would most of the footguns be solved by quoting all of the strings? e.g: "countries": - "ca" - "no" - "us"
- kevincox 5y ago
  Yes, but now you are losing a lot of the clean syntax that causes most people to use YAML in the first place. There is a reason that most people don't write YAML like JSON with trailing commas and comments, it is nice to cut most of this noise.
  - meowface 5y ago
    You can also use a stricter subset of YAML that removes things like the "no" footgun. Plenty of such strict parsers exist across languages. Maybe it's no longer technically YAML at that point, but you get all the nice parts of YAML without having to revamp everything with static typing.
Spivak 5y ago
So yes it’s a footgun but it makes some sense. Most people wouldn’t really complain about true not being equivalent to “true” or 100 not keeping it “100”. People just aren’t used to yes/no being reserved words. Ruby’s klass is a funny workaround to this. enable_feature: yes Is totally natural. Nobody reads the spec though. If you’re outputting YAML documents with string builders you’re headed for ruin no matter what. You don’t need Dhall, you need yaml.dump which handles the types too.

CBLT 5y ago

I agree that the problem is one of quicker feedback - the dev cycle should involve a program checking the yaml correctness (using types or otherwise) straight away and giving a useful error message. Too often I've seen incorrect yaml checked into git that fails with a cryptic error when deploying the application. The strength of types, in my opinion, is composability. Most config files I've seen have ultimately pulled in input from another source and used that to create their output. Types would allow the configuration to be checked for correctness even in the face of unknowns.