3 ms·

> And in some cases something meant to be a string is winding up unquoted, and being interpreted as something else on load? In this particular case, a timestam

> And in some cases something meant to be a string is winding up unquoted, and being interpreted as something else on load? In this particular case, a timestamp with "UTC" in it should not be interpreted as a timestamp, and older versions of psych would interpret it as a timestamp even though the spec says it's not valid. > Okay, yeah, tldr, we can stick with: YAML's data/processing model ends up being way too complex making it's behavior hard to predict and hard to maintain consistent between parsers/versions. Absolutely. If we eliminated implicit strings, it would make life lots easier. OTOH, you could just use JSON. :-D

jrochkind1 12y ago
Me, I'd keep implicit Strings (meaning optional to use quotes, for convenience), but stick to JSON-compatible data types. For most cases where YAML is used, what's really wnated is something that is pretty much exactly as expressive as json (no more), but easier and neater to write/read by hand. Of course, I realize the devil is in the details, and that may be what those developing YAML thought they were doing, but always adding just one more tiny thing that would be useful too. Complexity vs flexibility, one of the fundamental tensions of software design. I see how we got here through good intentions, but in retrospect YAML made some decisions on this balance that most of us would do differently. Or, did those designing YAML realize what a fundamental part of the ruby ecosystem it was to become, and what the implications of that were? Maybe part of the lesson is that some things really do need to be carefully designed, not just iteratively designed "you can always fix it later" by an ever-changing community of volunteers; is that part of what happened with YAML spec and implementations and uses? Also, thanks for explaining the bug-fix as part of the story, that makes a lot more sense. I understand that bug fixes will inevitably sometimes be backward-incompat. I think it has maybe been consistently under-estimated how important/useful it would to allow upgrades of ruby itself while keeping the exact same YAML processor and version. The psych/syck stuff ended up being one of the biggest pain points for many people way back in 1.8.7->1.9.3 too. Most gems ended up compatible with multiple ruby versions, so you could upgrade ruby versions while keeping your gem dependencies identical. YAML serializing/parsing, so fundamental, where minor differences in implementation can have disastrous consequences, was a painful exception.

jrochkind1 12y ago

Me, I'd keep implicit Strings (meaning optional to use quotes, for convenience), but stick to JSON-compatible data types. For most cases where YAML is used, what's really wnated is something that is pretty much exactly as expressive as json (no more), but easier and neater to write/read by hand. Of course, I realize the devil is in the details, and that may be what those developing YAML thought they were doing, but always adding just one more tiny thing that would be useful too. Complexity vs flexibility, one of the fundamental tensions of software design. I see how we got here through good intentions, but in retrospect YAML made some decisions on this balance that most of us would do differently. Or, did those designing YAML realize what a fundamental part of the ruby ecosystem it was to become, and what the implications of that were? Maybe part of the lesson is that some things really do need to be carefully designed, not just iteratively designed "you can always fix it later" by an ever-changing community of volunteers; is that part of what happened with YAML spec and implementations and uses? Also, thanks for explaining the bug-fix as part of the story, that makes a lot more sense. I understand that bug fixes will inevitably sometimes be backward-incompat. I think it has maybe been consistently under-estimated how important/useful it would to allow upgrades of ruby itself while keeping the exact same YAML processor and version. The psych/syck stuff ended up being one of the biggest pain points for many people way back in 1.8.7->1.9.3 too. Most gems ended up compatible with multiple ruby versions, so you could upgrade ruby versions while keeping your gem dependencies identical. YAML serializing/parsing, so fundamental, where minor differences in implementation can have disastrous consequences, was a painful exception.