Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

Post reply on HN
Print view View original

131–140 of 412 posts

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

#131

Post by allanbreyes »

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 design decisions in YAML strike me as a simple vs. easy[2] tradeoff, where the authors opted for "easy," at the expense of simplicity. I (and I assume others) mostly use YAML for configuration. I need my config files to be dead simple, explicit, and predictable. Easy can take a back seat.

[1]: http://yaml.org/type/bool.html [2]: https://www.infoq.com/presentations/Simple-Made-Easy

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

#132

Post by biztos »

twodave wrote: post #54
mschuster91 wrote: post #36

Earlier quoted context omitted.

> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

In our JSON config files we do: { "ConfigKeyComment": "This is for blah blah blah", "ConfigKey": "Foo" } Obviously this wouldn't work in all cases (you're putting more work on your parser to interpret unused keys basically), but if we're talking config files specifically, I see this as an acceptable approach since there's little chance you'll be parsing such files more than once each (plus, writing a simple tool to s…

I've tried something similar but found it way too painful if the comments need to be long...

    # Never enable this config, because if you do the space-time
    # continuum will collapse into itself and the cloud servers
    # will disappear in a puff of steam. However, if you really
    # must enable it, remember that it's boolean and go read
    # TICKET-8675309 for the extensive list of side effects.
    TurboFactorRenoberation = false
...so people just end up writing stuff like:

    {
        "ConfigKeyComment": "TICKET-8675309",
        "ConfigKey": "TurboFactorRenoberation",
        "ConfigVal": false
    }
[edit]: formatting

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

#133

Post by madhadron »

Since we're all chiming in with configuration formats, here's two more nice ones:

1. If you're writing Lisp, just read S-expressions in.

2. Use Python or Skylark and have a step that executes it into a configuration format. Obviously this is not something you would want to use for a data interchange format, but no one thinks that they can blindly run a random hunk of untrusted Python. Right? ...Right?

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

#134

Post by cesarb »

lomnakkus wrote: post #106
gaius wrote: post #99

Earlier quoted context omitted.

JSON lacks comments (both line-level and block level) “_comment”: “blah blah blah”, Simples

That doesn't work if you use a strict parser where superfluous fields are an error. It's quite rare, but there are good use cases for that kind of strictness.

Or when no fields are superfluous. For instance, when the code iterates over all the fields and does something with each, instead of just looking for known keys.

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

#135

Post by TimJYoung »

ChrisSD wrote: post #11
tootie wrote: post #2

We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.

To be quite honest I dislike using XML for human editable configuration files. Variations on Microsoft's .ini files (such as TOML) seem to work best for that, IMHO.

We use .ini files for all of our settings in our products, and they work great most of the time. The only weirdness creeps in when you try to store things with embedded CRLFs and need to escape/unescape them (not a big deal), and storing lists of things is a little difficult.

JSON is great in terms of flexibility, but .INI files are really easy to read because everything is on the left side of the screen/window at all times.

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

#136

Post by furgooswft13 »

wolfgang42 wrote: post #122
GordonS wrote: post #92

Earlier quoted context omitted.

> but the need for commas at all when there is a newline right next to it JSON is often minified though - you're going to need something to use as a delimiter

Newline and comma are both 1 byte. You could specify that either is acceptable. Actually, I think you could leave out the delimiter altogether and still be syntactically unambiguous, since quotes are required around keys: "key1":"value1""key2":2.75"key3":true"key4":"whatever" though this looks terrible and there's probably some edge case I've forgotten. (Also it misses the point of JSON in that it's no longer valid J…

> you should be calling JSON.parse() not eval()

The one major reason I could see to use "JSON" as a conf file is in trusted node.js apps because you can then easily embed functions and logic in them if you need more advanced/customizable configurations. And you can do it with full syntax highlighting in your editor. And comments, and trailing commas, and naked keys.

Of course this is no longer JSON, it's straight up Javascript config files. But it has come in handy a few times when I want to override standard behavior on a per config basis, and most of the file is still just plain key: val

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

#137

Post by emodendroket »

tlb wrote: post #74
mschuster91 wrote: post #36

Earlier quoted context omitted.

> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

If you're going to do this kind of thing why would you not add a standard date format

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

#138

Post by Edmond »

dmitriid wrote: post #126
Edmond wrote: post #118

Earlier quoted context omitted.

thanks for the broken link pointer, it will be fixed. the "So Much More" button is a link to the docs:) Here's the ConfigNode doc: http://codesolvent.com/doc/config-node/ The platform doc: http://codesolvent.com/doc/webapps/ If you're interested, send me an email (in my profile).

> the "So Much More" button is a link to the docs:) Yeah... No. It looks like a link to yet more marketing-speak, and the page it links to answers zero answers as to why I would ever want it. Hiding the product README in some nested folder in the source code is also a brilliant idea. So, nope. I’m sticking to my YMLs and EDNs.

I am afraid your own cynicism (warranted or not) might be really blinding you here...I am not sure whether to feel proud of myself when my writing is designated "marketing speak" :)

The documentation link LITERALLY shows how to use the product.

Nothing is hidden, if you read the platform docs (http://codesolvent.com/doc/webapps/) you see it says:

"Solvent is an integrated platform that combines an application container (jetty), a middle-ware and a developer environment to provide a complete solution for delivering web applications."

ConfigNode is something you'll put on a server as a config management environment, the output can be json/yaml/xml..etc

I think you might find it quite unique if you just give it a chance (no marketing) :)

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

#139

Post by ngrilly »

kodablah wrote: post #130
ngrilly wrote: post #75

JSON + comments + trailing commas + naked keys + multiline strings would be a great alternative. Maybe something like JSON5.

You'd really like HOCON[0] then. Just a bit too complicated to see wide adoption I'm afraid. 0 - https://github.com/lightbend/config/blob/master/HOCON.md

Interesting, but, as you wrote, it's a bit too much complex, and there is too much syntactic variations for my taste.

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

#140

Post by emodendroket »

dagw wrote: post #20
Alex3917 wrote: post #6

With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…

In contrast, JSON is super intuitive and basically self documenting. Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.

See how much fun these people have trying to figure out why their application crashes because they put a tab instead of spaces into the YAML file.
Post reply on HN