3 ms·

If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.c

If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/

dmix 8y ago
God, I hate programming some times.
- krapp 8y ago
  Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?
  - dmix 8y ago
    That might solve one problem but fighting your tools and occasionally hating the complex giant messes we've engineered is a fact of life for any programmer. I absolutely love programming, just not always the process. We get better and better tools each year but it still seems unavoidable. We're ultimately building incredibly complex systems with each layer using multiple development approaches, style choices, language choices, degrees of quality/time investment by the creator, etc. TLDR: you can't help bang your head against the wall in any real-world day-to-day programming
  - rbanffy 8y ago
    You can always use a subset of YAML (much like we do with JavaScript these days).
    - SamWhited 8y ago
      That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky behavior that can be abused too like pointers). Using a subset creates more work for the developer, so many just won't bother (if they even know that it's using a subset and they have to do more work at all), which leads to issues.
      - rbanffy 8y ago
        We can agree to generate a subset - the things we won't add to a certain stream - even if we are more lax in what we accept by using full parsers.
        SamWhited 8y ago
        We can agree, but that doesn't mean that others won't do it anyways; unless you operate in a silo, it's not likely that you're the only one writing software to use your system. Standards get written and implemented by lots of people, and even tooling like Docker gets alternative implementations.
  - SamWhited 8y ago
    Unfortunately, this isn't practical. For any of my own tools I will never use YAML, but I don't just use my own tools, and reinventing the wheel just to not use YAML has its own problems which are (in some cases) worse.
SamWhited 8y ago
I end up hitting bare string implicit casting problems constantly. I also end up catching them in code review when codeworkers do it constantly and yet I still end up doing it too. This might be the best example of why YAML is overengineered garbage (that and the fact that the spec is 83 pages long and has pointers… WTF?).

dmix 8y ago

God, I hate programming some times.

krapp 8y ago
Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?
- dmix 8y ago
  That might solve one problem but fighting your tools and occasionally hating the complex giant messes we've engineered is a fact of life for any programmer. I absolutely love programming, just not always the process. We get better and better tools each year but it still seems unavoidable. We're ultimately building incredibly complex systems with each layer using multiple development approaches, style choices, language choices, degrees of quality/time investment by the creator, etc. TLDR: you can't help bang your head against the wall in any real-world day-to-day programming
- rbanffy 8y ago
  You can always use a subset of YAML (much like we do with JavaScript these days).
  - SamWhited 8y ago
    That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky behavior that can be abused too like pointers). Using a subset creates more work for the developer, so many just won't bother (if they even know that it's using a subset and they have to do more work at all), which leads to issues.
    - rbanffy 8y ago
      We can agree to generate a subset - the things we won't add to a certain stream - even if we are more lax in what we accept by using full parsers.
      - SamWhited 8y ago
        We can agree, but that doesn't mean that others won't do it anyways; unless you operate in a silo, it's not likely that you're the only one writing software to use your system. Standards get written and implemented by lots of people, and even tooling like Docker gets alternative implementations.
- SamWhited 8y ago
  Unfortunately, this isn't practical. For any of my own tools I will never use YAML, but I don't just use my own tools, and reinventing the wheel just to not use YAML has its own problems which are (in some cases) worse.

SamWhited 8y ago

I end up hitting bare string implicit casting problems constantly. I also end up catching them in code review when codeworkers do it constantly and yet I still end up doing it too. This might be the best example of why YAML is overengineered garbage (that and the fact that the spec is 83 pages long and has pointers… WTF?).