YAML: probably not so great after all (2017) • Hacker News Board

Re: YAML: probably not so great after all (2017)

#241

Post by Carpetsmoker » Wed, Jun 20, 2018, 10:47 PM UTC

jokoon wrote: post #115

> Don’t get me wrong, it’s not like YAML is absolutely terrible – it’s certainly not as problematic as using JSON – but it’s not exactly great either. Well at least it's the least worst then, do that make it the best? Frankly I hope the future will be make with indented languages. Curly braces languages often allows too much liberty, and it's annoying. The fact that go enforce the curly brace style is really the tipp…

I like the "Ruby approach" of:

    if foo
        ...
    else 
        ...
    end

It solves some of the issues that you can have with Python, while at the same time also avoiding the whole nonsense with the braces. I find it's a good trade-off between the strengths of both approaches.

Re: YAML: probably not so great after all (2017)

#242

Post by tetron » Wed, Jun 20, 2018, 10:51 PM UTC

Schemas and validation for YAML (and JSON):

http://github.com/common-workflow-language/schema_salad

Re: YAML: probably not so great after all (2017)

#243

Post by aldanor » Wed, Jun 20, 2018, 10:54 PM UTC

allanbreyes wrote: post #131

I'd like to propose the "YAML-NOrway Law." "Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway." Example: NI: Nicaragua NL: Netherlands NO: Norway # boom! `NO` is parsed as a boolean type, which with the YAML 1.1 spec, there are 22 options to write "true" or "false."[1] For that example, you have wrap "NO" in quotes to get the expected result. This, along with many of the…

This was fixed in YAML 1.2 though? So, e.g., in Python you'd just use ruamel.yaml instead of pyyaml.

That doesn't help you, of course, when using a multitude of existing systems whose yaml parsers are based on 1.1...

Re: YAML: probably not so great after all (2017)

#244

Post by bmurphy1976 » Wed, Jun 20, 2018, 10:55 PM UTC

freedomben wrote: post #205

crdoconnor wrote: post #194

Earlier quoted context omitted.

>YAML is complex and could use a hair cut. Out of curiosity, did you see the parser linked to at the end of the article? ( https://github.com/crdoconnor/strictyaml ) That was my attempt at giving YAML a haircut. I'd be curious to know what you thought. Thank you for creating YAML, by the way. Even though part of that rant was quoted from me, I'm not negative on it like the author - I think the core was brilliantly de…

Is there an implementation of strict yaml that you know of for Ruby?

If you are writing a new YAML implementation, then yeah, you want a simpler spec to follow.

If on the other hand you are using a YAML library... I've had pretty good success using YAML compatibly across Python, Ruby, C# and Go projects. Do you have a particular issue in mind that the existing Ruby implementation doesn't address?

Re: YAML: probably not so great after all (2017)

#245

Post by Carpetsmoker » Wed, Jun 20, 2018, 10:59 PM UTC

jrochkind1 wrote: post #25

> Are you sure that every YAML parser will treat foo:bar as a string, or 0x42 as the integer 42, etc.? Definitely not. I'd expect 0x42 to be 66. (Not kidding, if 0x42 means hex notation!). Point taken.

Yeah, that was an error >_< I fixed it. Thanks!

Re: YAML: probably not so great after all (2017)

#246

Post by akavel » Wed, Jun 20, 2018, 10:59 PM UTC

wwweston wrote: post #204

chx wrote: post #63

Earlier quoted context omitted.

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html (and is still officially deemed useful for writing them)

Re: YAML: probably not so great after all (2017)

#247

Post by coherentpony » Wed, Jun 20, 2018, 10:59 PM UTC

arp242 wrote: post #226

sandov wrote: post #206

Earlier quoted context omitted.

I love the clean style of your website.

Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.

Penalised? By whom?

Re: YAML: probably not so great after all (2017)

#248

Post by bmurphy1976 » Wed, Jun 20, 2018, 11:00 PM UTC

allanbreyes wrote: post #131

I'd like to propose the "YAML-NOrway Law." "Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway." Example: NI: Nicaragua NL: Netherlands NO: Norway # boom! `NO` is parsed as a boolean type, which with the YAML 1.1 spec, there are 22 options to write "true" or "false."[1] For that example, you have wrap "NO" in quotes to get the expected result. This, along with many of the…

I've been bit by the string made out of digits and starts with 0 thing a couple times. In this case it gets interpreted as a number and drops leading zeroes. I quickly learned to quote all my strings.

I'd still love for a better means to resolve ambiguities like this, but I've found always quoting to be a fairly reliable approach.

Re: YAML: probably not so great after all (2017)

#249

Post by shruubi » Wed, Jun 20, 2018, 11:02 PM UTC

Honestly, I can't stand YAML. Every time I need to read a YAML file I also need to bring up a reference for what the syntax is because to me, none of it is immediately obvious.

Personally, I don't understand why all these projects have defaulted to using such an esoteric markup language.

Re: YAML: probably not so great after all (2017)

#250

Post by ravenstine » Wed, Jun 20, 2018, 11:04 PM UTC

> Loading a user-provided (untrusted) YAML string needs careful consideration.

Why would you ever use YAML for user-provided input? At that point, it's better to just use JSON.

> Many other languages (including Ruby and PHP1) are also unsafe by default. Searching for yaml.load on GitHub gives a whopping 2.8 million results. yaml.safe_load only gives 26,000 results.

Maybe that's everyone's using JSON where it would be unsafe to use YAML.

> YAML files can be hard to edit, and this difficulty grows fast as the file gets larger.

And... this isn't the case for XML or JSON?

Ok, so reindenting a section might be a pain, but if your YAML is containing large amounts of data, maybe that data doesn't belong in that format if you're manually editing the YAML.

> especially since 2-space indentation is the norm and tab indentation is forbidden

Good. ;)

> And accidentally getting the indentation wrong often isn’t an error; it will often just deserialize to something you didn’t intend. Happy debugging!

Which is unlikely to happen if you're using a YAML library or only editing small-ish config files by hand.

---

As noted, YAML has a lot of quirks. As a configuration language, I love it and am used to the little edge cases. Could it be better? Definitely. But I would still consider YAML to be great in the domain where it excels: human-readable configuration. Using it to store and transmit large amounts of data, especially in ways where a human is manually editing the YAML, is a terrible idea.