4 ms·
>YAML is what people turn to who need these kind of advanced feautures Most people don't use these features.
by crdoconnor 10y ago
>YAML is what people turn to who need these kind of advanced feautures
Most people don't use these features.
- Sir_Substance 10y agoBut twelvechairs' contention is that the people who do need them turn to YAML :)
- crdoconnor 10y agoExcept the people who use YAML don't seem to use them: https://github.com/search?o=desc&p=2&q=data+language%3AYAML&ref=searchresults&s=indexed&type=Code&utf8=%E2%9C%93 https://github.com/search?o=desc&p=2&q=data+language%3AYAML&...
- kelseyfrancis 10y agoI'm not sure what your search query is supposed to prove. That something is rare doesn't mean it doesn't exist. I have personally used this YAML feature, albeit very rarely, obviously.
- timv 10y agoHis query is attempting to show that while > YAML is what people turn to who need these kind of advanced feautures might be literally true, it is also true that YAML is what many people turn to even if they don't use those features So the original concern of > Powerful but pretty catastrophic if you use (naive) recursion to analyze a user-submitted data structure. is probably reasonable. There is a pretty good likelihood that many YAML users (i.e. the app developers) are unaware of the power exposed in the format, and the possible consequences of parsing & walking user input. It brings back all sorts of memories of XML entity attacks, etc. When developers build simple data interchange methods on top of complex formats that they don't fully understand, all sorts of issues emerge. It's not YAML's problem per se - it's very helpful that there is a commonly used, complex data format for people who need such features. It would be far worse if everyone was inventing their own solution for this - but the reality on the ground is still pretty messy.
- crdoconnor 10y ago>It would be far worse if everyone was inventing their own solution for this They are - HJSON, JSON5, TOML, etc. Most of these reference YAML's overcomplicated spec as a reason for their existence.
- cm3 10y agoIt's how config is shared in, say, .gitlab-ci.yml or .travis.yml. So, it is used and a widely documented use case at that. Not recursively, of course.
- crdoconnor 10y agoI've never seen a node anchor and reference used in .gitlab or .travis, let alone a recursive one. Just text, list & associative array.
- jdmarble 10y agoThe most popular repository on GitLab.com uses these features extensively: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-...
- crdoconnor 10y agoFair enough. It does seem to be a rarely used feature though. Furthermore it confuses non-programmers who otherwise are happy with YAML (I've tested this, it really does). Given all of this, and given that what it does can be easily achieved in other ways that don't require the feature, I think it's a net negative overall to have it in the spec.
- cm3 10y agoI may be rarely used, generally speaking, but it's used a lot in CI configs. The linked example is the typical use case, and it's documented in both CI services' config section. I'm certain this feature is a major reason why YAML was chosen for CI config over TOML or JSON, and the way it's used in those config files is, as I said, _not_ recursive, so the issue discussed here isn't relevant. Rejecting recursive definitions can be a sensible improvement. What other ways do you have in mind that would be a viable replacement?
- 10y ago