3 ms·

Okay, permit me a curmudgeonly rant. As someone who has implemented a YAML parser and spent way too much time dissecting the spec along with analyzing various i

Okay, permit me a curmudgeonly rant. As someone who has implemented a YAML parser and spent way too much time dissecting the spec along with analyzing various implementations, StrictYAML smacks of simple ignorance. The page describing the project's raison d'être [0] is mostly a collection of incredulous statements, sprinkled with lovely factual errors. Heck, the point about implicit typing even links to the YAML 1.2 spec, claiming that implicit types are intended behavior, while the spec explicitly makes the opposite clear. That said, a lot of the common complaints about YAML are rooted in the fact that almost all end user libraries are stuck at YAML 1.1. This is mostly because everyone (including PyYAML) relies on libyaml, the primary culprit. IMHO, YAML 1.2 is quite nice, and I wish we could fix libyaml instead of everyone and their dog inventing their own half-baked language to scratch an itch. Or perhaps even better, the primary inventor of YAML is currently avidly working on YAMLScript[1] which is a much more radical idea on programming and config language design, while all being YAML backwards-compatible. [0]:https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/ [1]:https://yamlscript.org/ https://yamlscript.org/

Ygg2 2y ago
> YAML 1.2 is quite nice, and I wish we could fix libyaml instead of everyone and their dog inventing their own half-baked language to scratch an itch. YAML 1.2 is categorically better than YAML 1.1. That said: It still suffers from many things that sucks about YAML. From user perspective, it suffers from anchors being a thing (billion laughs attack), duplicate keys, complex object as keys (WTF is this feature even), and loading YAML to objects. From an implementation perspective, the quoted scalars, several string forms, and huge number of corner cases really makes parsers difficult to write.
- xelxebar 2y ago
  I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One of the aims of my dayaml[0] project is to explore a completely different formalization that rationalizes out the non-fundamental sharp edges. That said, there really aren't that many special cases. A lot of the them are UI features, arguably endemic to the problem space in one form or another. The deficiencies you see in the language, however, don't ring true with me. They are mostly implementation deficiencies: - Anchors are just pointers. YAML can efficiently represent generic object graphs, but if a loader copies those pointers into a billion laughs, that's an issue with the implementation decision. Usually, it comes down to assuming that YAML graphs are always trees, which will always turn cyclic graphs into infinite tree unfoldings. - Keys are explicitly specced as unique [1]. Not really sure why libyaml and friends get this wrong. - Loading YAML to objects is explicitly designed to represent the native data structures of your language. It's a serialization format by design. That's why it loads into objects. That's why it has complex keys. We can certainly discuss whether YAML is appropriate as a configuration language or not, but YAML is first and foremost designed as a language-agnostic textual representation of object graphs. The spec goes well out of it's way to make this clear, and viewing YAML for what it is, instead of a configuration language, really makes the apparent oddities disappear IMHO. [0]:https://github.com/xelxebar/dayaml https://github.com/xelxebar/dayaml [1]:https://yaml.org/spec/1.2.2/#mapping https://yaml.org/spec/1.2.2/#mapping [2]:https://yaml.org/spec/1.2.2/#11-goals https://yaml.org/spec/1.2.2/#11-goals
  - Ygg2 2y ago
    > Anchors are just pointers. > That's why it has complex keys. Yes. And it leads to exploits or errors. The dumber the serialization format, the better. JSON has thrived without these mis-features. And most stuff I've seen in the wild doesn't use the exotic features anyway. The format user should worry about converting nodes to references, and complex keys are something few users ask for.
    - xelxebar 2y ago
      > it leads to exploits or errors You are blaming implementation failures on the language design. That's kind of my whole gripe. Instead of wasting cycles on inventing new languages, I wish we'd pool resources into fixing libyaml. > most stuff I've seen in the wild doesn't use the exotic features anyway Mostly due to lack of awareness. Ruby, Python, JavaScript Rust, Java, etc. all allow mostly arbitrary objects for keys. It's only confusing if you conflate dictionaries/maps for objects. In the scientific computing community, it's not unheard of to see lists as keys in YAML documents, which is really convenient if that serializes to exactly the data model you're working.
deleted 2y ago
[deleted]

Ygg2 2y ago

> YAML 1.2 is quite nice, and I wish we could fix libyaml instead of everyone and their dog inventing their own half-baked language to scratch an itch. YAML 1.2 is categorically better than YAML 1.1. That said: It still suffers from many things that sucks about YAML. From user perspective, it suffers from anchors being a thing (billion laughs attack), duplicate keys, complex object as keys (WTF is this feature even), and loading YAML to objects. From an implementation perspective, the quoted scalars, several string forms, and huge number of corner cases really makes parsers difficult to write.

xelxebar 2y ago
I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One of the aims of my dayaml[0] project is to explore a completely different formalization that rationalizes out the non-fundamental sharp edges. That said, there really aren't that many special cases. A lot of the them are UI features, arguably endemic to the problem space in one form or another. The deficiencies you see in the language, however, don't ring true with me. They are mostly implementation deficiencies: - Anchors are just pointers. YAML can efficiently represent generic object graphs, but if a loader copies those pointers into a billion laughs, that's an issue with the implementation decision. Usually, it comes down to assuming that YAML graphs are always trees, which will always turn cyclic graphs into infinite tree unfoldings. - Keys are explicitly specced as unique [1]. Not really sure why libyaml and friends get this wrong. - Loading YAML to objects is explicitly designed to represent the native data structures of your language. It's a serialization format by design. That's why it loads into objects. That's why it has complex keys. We can certainly discuss whether YAML is appropriate as a configuration language or not, but YAML is first and foremost designed as a language-agnostic textual representation of object graphs. The spec goes well out of it's way to make this clear, and viewing YAML for what it is, instead of a configuration language, really makes the apparent oddities disappear IMHO. [0]:https://github.com/xelxebar/dayaml https://github.com/xelxebar/dayaml [1]:https://yaml.org/spec/1.2.2/#mapping https://yaml.org/spec/1.2.2/#mapping [2]:https://yaml.org/spec/1.2.2/#11-goals https://yaml.org/spec/1.2.2/#11-goals
- Ygg2 2y ago
  > Anchors are just pointers. > That's why it has complex keys. Yes. And it leads to exploits or errors. The dumber the serialization format, the better. JSON has thrived without these mis-features. And most stuff I've seen in the wild doesn't use the exotic features anyway. The format user should worry about converting nodes to references, and complex keys are something few users ask for.
  - xelxebar 2y ago
    > it leads to exploits or errors You are blaming implementation failures on the language design. That's kind of my whole gripe. Instead of wasting cycles on inventing new languages, I wish we'd pool resources into fixing libyaml. > most stuff I've seen in the wild doesn't use the exotic features anyway Mostly due to lack of awareness. Ruby, Python, JavaScript Rust, Java, etc. all allow mostly arbitrary objects for keys. It's only confusing if you conflate dictionaries/maps for objects. In the scientific computing community, it's not unheard of to see lists as keys in YAML documents, which is really convenient if that serializes to exactly the data model you're working.

deleted 2y ago

[deleted]