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

101–110 of 412 posts

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

#101

Post by ivan4th »

outworlder wrote: post #95
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.

Well, if you go deeper down the rabbit hole, XML was a complete and utter waste of time. This problem was solved in the 60's with S-Expressions.

Yeah... I'm a diehard Common Lisp user, and when I saw YAML+go-template used for Kubernetes Helm templates, with some extra hacks to take care of indentation shifts... I felt almost physical pain.

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

#102

Post by cpburns2009 »

bryanlarsen wrote: post #69

A thread hating on YAML without a mention of the bastardized YAML that ansible uses? Ansible extends yaml so that: cmd: a b c is actually but not quite identical to: cmd: ["a", "b", "c"] It also embeds JINJA2 templating part-way (!) through the YAML parsing process. The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/r…

Oh god, Ansible is exactly why I don't like YAML or Jinja2. I never know what needs to be quoted, what's inlined, what needs to be wrapped in "{{ }}", and what expressions are supported. But once you get the syntax right, it works great.

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

#103

Post by _sdegutis »

I haven't found a markup language that I really prefer for configuration files, but JSON has been reasonably nice to me in NPM configurations and VS Code settings and I haven't ran into problems yet. I understand the motivation for TOML but it has the same ambiguity problems that YAML does. There's something to be said for not being too flexible, or it'll fall into the same trap as AppleScript did. Humans might prefer the convenience of ultra-flexibility at first, but sooner or later our intuition will just not match up with the actual rules, and we'll have to spend longer than we wanted to looking up arcane syntax documentation. That's been my experience with YAML anyway, like every single time.

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

#104

Post by [deleted] »

Zamicol wrote: post #57
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.

>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. -Douglas Crockford, creator of JSON There is no issue using JSON with comments for a config file.

[deleted]

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

#105

Post by organsnyder »

commandlinefan wrote: post #32
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.

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: ApplicationName WhizBang ... So that they could pass schema validation and still have some hope of extensibility.

Why not just

?

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

#106

Post by lomnakkus »

gaius wrote: post #99
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.

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.

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

#107

Post by sk5t »

ebikelaw wrote: post #88
clarkevans wrote: post #34

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…

JSON definitely did exist 20 years ago.

JavaScript objects, yes, but not JSON. Folks were deep into XML as a message format.

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

#108

Post by dmitriid »

Edmond wrote: post #41

Object graphs are the answer to the endless iteration on the right config format: http://codesolvent.com/config-node/ it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.

The answer is a marketing website with market-speak all over the page and 'Executable not found "/eula"' when trying to read Terms and Conditions?

Edit: I actually did download whatever this thing is. What is this thing? The README is Jetty's README. There are dozens of dirs with crap^W code in them.

It really is an answer to YAML/JSON, surely.

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

#109

Post by rocmcd »

bryanlarsen wrote: post #69

A thread hating on YAML without a mention of the bastardized YAML that ansible uses? Ansible extends yaml so that: cmd: a b c is actually but not quite identical to: cmd: ["a", "b", "c"] It also embeds JINJA2 templating part-way (!) through the YAML parsing process. The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/r…

I'm not an expert by any means, but I'm pretty sure that Ansible uses vanilla YAML (no 'bastardization').

Your first example is an Ansible convenience feature, it's not extending or changing the YAML syntax in any way. You can simply specify `cmd` values as lists or strings, since working with one or the other may be easier depending on the use case.

The templating is unfortunate in some areas, especially where the jinja2 syntax conflicts with what YAML expects (for example starting an object with '{'). That's due to a combination of templating engine choice and YAML, though, and not some custom implementation of YAML. Unless I'm misunderstanding?

I do think going with YAML was a trade-off for Ansible, but it's hard to see Ansible getting to where it is today if it had gone with a custom DSL (or JSON, thank god). I'd take Ansible's YAML over Chef's Ruby or CloudFormation's JSON any day.

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

#110

Post by slavik81 »

TillE wrote: post #8
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.

XML is in that odd middle-ground where it's usually human-readable, but also a huge pain in the ass to write. It's great at what it was intended for, as a data interchange format. For a general-purpose human-writable structured data format, I guess the ugly nonstandard hack that is "JSON with comments" is probably good. It's certainly faster to parse than YAML.

> It's great at what it was intended for, as a data interchange format.

XML's incredible verbosity is a problem for computers too. I've spent time performance-tuning message parsing code that had no good reason to be slow except that our use of XML bloated the data and decoding time by an order of magnitude or more compared to a binary protocol with a schema.

Post reply on HN