Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

161–170 of 412 posts

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

#161
post #9
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.

My biggest complaint with JSON is the lack of support for comments. For that reason, it's hard to take it seriously for human-maintained configurations.

"comment": "blah" is one hack.

it's a shame json doesn't support them though. oh well. would be nice to restart the universe and get all this right next time. :-)

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

#162
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".

> JSON doesn't support comments eh? { "firstName": "John", "lastName": "Smith", "comment": "foo", } I know it isn't the same as #comments, but who cares really.

The trouble there is that your comments come in-band. What if you're trying to serialise something and you don't have the power to insist that it's not a dictionary with "comment" as a key?

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

#163
I've been playing with Home Assistant[0] recently and, as a result, getting exposed to YAML. I don't find it pleasant to work with at all. I'm sure a big part of that is how Home Assistant uses YAML for automation stuff[1] that would probably be better served by a real programming language.

I think a big part of the unpleasantness comes from how non-obvious some things are. For example, why does the first automation example require a "-" in front of "platform" (under "trigger"), but the second doesn't? The comments explain when it's required, but not why? Shouldn't the parser be able to figure it out from the significant whitespace?

I found it so unpleasant that I'm using Node-RED[2] to do anything even vaguely automation related and have relegated Home Assistant to being the UI and communications abstraction layer.

In contrast, XML, while overly verbose, has a more reasonable structure. I haven't played with JSON much, but it also seems pretty reasonable.

[0] https://www.home-assistant.io/

[1] https://www.home-assistant.io/docs/automation/examples/

[2] https://nodered.org/

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

#164
Yes, I love YAML in general. The complaints about big files can be alleviated with a good editor that collapses blocks and draws indentation guides.

But the author is mostly right, when adding support for YAML to my code I spend a lot of time disabling all of its nifty misfeatures. Wish it was simply an indented JSON with comments and fewer quotes.

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

#165
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".

> JSON doesn't support comments eh? { "firstName": "John", "lastName": "Smith", "comment": "foo", } I know it isn't the same as #comments, but who cares really.

How do I do something like:

{ # comment with a note about the value of foo "foo": "bar", # comment with a note about the value of baz "baz": "qux" }

Without driving myself and future readers insane with fooComments and bazComments?

What if I need a multiline comment explaining a yak-shaving story for why a key is set to a certain value?

What if the object in question is a set of keyword arguments, and adding new fields changes the behavior of whaever is parsing the document?

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

#166
post #134

Earlier quoted context omitted.

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.

Or when the place you need to put the comment doesn't happen to be inside an object literal.

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

#167
As a general rule of thumb: Never use yet another non-markup language designed by people who claimed to be designing yet another markup language from the very outset, then after somebody awkwardly pointed out that what they'd designed wasn't actually a markup language, they invent a backronym to contradict that embarrassing historical fact.

It just makes me wonder what the hell they thought they were doing all that time...

It's like designing a tool called YACC, and ending up with Yet Another Interpreter Interpreter!

It's like a standard for storing all your pornography in a folder called "Definitely Not Pornography".

https://en.wikipedia.org/wiki/YAML

>Originally YAML was said to mean Yet Another Markup Language, referencing its purpose as a markup language with the yet another construct, but it was then repurposed as YAML Ain't Markup Language, a recursive acronym, to distinguish its purpose as data-oriented, rather than document markup.

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

#168

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…

The implicit typing rules (ie, unquoted values) should have been application dependent. We debated this when we got started and I thought there was no "right" answer. Alas, Ingy was correct and I was wrong.

I appreciate your humility and professionalism in a discussion thread that holds a lot of criticism; suffice it to say, I should have practiced a bit more humility and a bit less "Monday morning quarterbacking" in my original post. And I should have read your comment on YAML's history. To right the record: you got _so_ much right with YAML, and it's unfair for me to cherry-pick this example 20 years later. Sincere apologies...

As the saying goes, "there are only two kinds of languages: the ones people complain about and the ones nobody uses." YAML, like any language, isn't perfect, but it's withheld the test of time and is used by software around the world—many have found it incredibly useful. Sincere thanks for your contribution and work.

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

#169

No body talks about SDLang (Simple Declarative Language) : https://sdlang.org/ An example : ``` // This is a node with a single string value title "Hello, World" // Multiple values are supported, too bookmarks 12 15 188 1234 // Nodes can have attributes author "Peter Parker" email="peter@example.org" active=true // Nodes can be arbitrarily nested contents { section "First section" { paragraph "This is the first parag…

I have not seen this before, thanks for sharing.

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

#170
I got blindsided by another obscure yml phrasing rule. Sometimes people couldn't pay online using our service and I couldn't figure out why. I tested the hell out of the payment module on our dev and UAT environments, but I just couldn't reproduce the issue.

Eventually I tracked it down to an ID inside a yml file. Turns out the live environment was running in 32 bit mode which interpenetrated the number as a string.

Post reply on HN