I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From

I think I get what the article is saying. I don't think they expressed it very well. Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-conn key: uri That valueFrom.secretKeyRef.{name, key} structure is an "exploded AST" — something that in any programming language, you'd be chastised for writing out as a structural-initialization literal, because there's so much stuff there that it's easy to screw it up and forget something. When attempting to express such a literal in most-any programming language, you'd expect to either have: • the Java "literal factory function" approach — some static function to call, that takes either other literals, or a single literal string encoding an expression in a DSL, as arguments, and then produces an initialized value-object; or • the Elixir "custom sigil" approach (there's probably a more popular language with this feature, but Elixir is what I know) — a macro or operator that takes in a raw string or lexemes encoding an expression in a DSL, and then codegens out to the appropriate structural-initialization literal. (Macros are better here, as incorrect DSL syntax can be caught at parse/compile time, just like incorrect syntax of the surrounding language.) ----- To be honest, I don't think I would want YAML to support either of these. YAML shouldn't be arbitrarily extendable; a YAML document should be a YAML document, parsed by any compliant parser. (There could be some Avro-like "embedded schema" format for YAML that enables this, but that format would be better as a layer on top of YAML, rather than being part of YAML itself.) What I would like in YAML, is support for built-in literal sugar for certain specific YAML structures. This is different in concept from YAML having support for a type, where that type must have some 1:1 native type on the host language side for it to encode/decode to. Instead, a "sugared structure" would involve 1. a YAML parser having a sub-parser for certain specific DSLs, where the output of this parser is a small, standardized-in-shape container structure, made out of regular YAML arrays, dicts, and scalars; 2. a YAML generator offering a configuration option to pattern-match on these standardized-in-shape structures, where recognized subtrees are swapped out in the emitted YAML for the appropriate sugared-literal representation. Examples of where this would be helpful include: DateTimes, URIs, UUIDs, Intervals... and that's basically it. There really aren't too many of these. The short list above represents basically the entirety of the set of types I've ever had YAML fall down on in the 10 years I've been generating/parsing YAML documents. For everything else, it works fine.