StrictYAML is a project that tries to fix some issues with YAML.
They set out to make tools, not standards, and that’s great.
They wanted to make a subset of YAML and a parser for it. Super
good approach. But then they don’t follow through on that idea. For
example, No is a boolean false in YAML but when StrictYAML reads it,
it’s a two-character string (if I understand their documentation
correctly). So you’ll end up with misleading bugs later. Maybe a
linter would’ve been better?
They disallow duplicate keys but so does the YAML standard as
far as I understand it. It’s good that it does, in order to be
compatible with JSON, but that’s a problem with both JSON and YAML
compared to HTML where a <body> can have many <p>. When I made
xj, which turns XML to JSON, I had to implement elements as objects
with one key, the element name, and the value is an array with the
children of the element because of this limitation in JSON. Attributes
in XML has the same limitation which is why attributes in the JSON
that xj emits has easier semantics.
They also forbid inline JSON which I think might be a mistake. The fact that YAML is a superset of JSON solves a lot of other problems people have with JSON (such as no comments).
YAML is a very finicky and stressful language to write. It’s difficult to remember the exact incantations of indentation and hyphenation to get what you want.
Coming from Lisp, I more often just use sexp for serialization. It’s the “it’s just already there so why not” solution for lispers.
I kind of have a love-hate relationship with YAML.
When I read YAML trying to think “What data structures, exactly, will this parse as?” then I’m gonna be miserable.
When I read YAML as a human as opposed to as “a human compiler”, that’s where it shines. That’s where I’m like “OK so this is the author and this is the date and this is the categories and this is the comment and this is that list of addresses and phone numbers”, like, if I can trick my mind out of “programmer brain” for a moment and just look at the data qua data, it’s great.
Of course, if I’m looking at the data because I’m trying to debug something, then that’s again where we’ve got problems that YAML (or StrictYAML) is not good at solving.
It’s sometimes tricky figuring out what’s a list and what isn’t a list and where the object boundaries lie when you are nesting maps in maps. It’s not a problem in “human reading mode”, it’s just an issue when I “try to program in YAML”. I mostly use YAML with Jekyll, which sometimes does additional string-splitting magic on top of YAML. All for the sake of DWIMminess and human-ness at the expense of clear and strict semantics.
StrictYAML has almost all of the drawbacks of YAML and as far as I can tell makes incompatible changes rather than being a true subset.
Use this linter instead of StrictYAML.