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

211–220 of 412 posts

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

#211

Post by clarkevans »

crdoconnor wrote: post #194
clarkevans wrote: post #125

Earlier quoted context omitted.

I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of u…

>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…

Thank you for StrictYAML I might just use it. It does look like a nice hair cut. You might wish to give Ingy a ring. He has been itching to move forward on a reduced/secure YAML subset.

That said, StrictYAML seems to be a tad bit more of a hair cut than I'd imagine. I'd keep nodes/anchors, since I think a graph storage model is underrated; I think that data processing techniques just haven't caught up with graph structures.

Further, I'm not sure everything can be easily typed based upon a schema. Hence, I'm not sure about completely dropping implicit types, perhaps you may want to provide a way for applications to resolve them if they wish. For example, an application may want to attempt to treat anything starting with "[" or "{" as JSON sub-tree. Perhaps keeping "!tag" but handing it off to the application to resolve might also be a good idea in this regard. Even so, typing should be done at the application level and default to something very boring.

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

#213

Post by EamonnMR »

skybrian wrote: post #181
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".

VS Code uses JSON with comments for config files. [1] Technically, this is not JSON. You won't be able to use a standard JSON parser without stripping comments first. But you can use a simple, JSON-like language with comments for config. [1] https://code.visualstudio.com/docs/languages/json#_json-with...

> you can use a simple, JSON-like language with comments for config.

YAML can be employed as a simple JSON-like language with comments.

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

#216

Post by krapp »

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.

>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.

You picked the wrong language... PHP comes with its own JSON parser. And INI and XML and even CSV.

But, the reason is that, generally, you want config files to describe data or state only. Yes, you could just make your config native code, but then the temptation to add functions and methods and logic to that becomes irresistible and soon your config is an application that needs its own config.

Config formats need to be simple, and preferably not Turing complete.

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

#217

Post by crooked-v »

EamonnMR wrote: post #213
skybrian wrote: post #181

Earlier quoted context omitted.

VS Code uses JSON with comments for config files. [1] Technically, this is not JSON. You won't be able to use a standard JSON parser without stripping comments first. But you can use a simple, JSON-like language with comments for config. [1] https://code.visualstudio.com/docs/languages/json#_json-with...

> you can use a simple, JSON-like language with comments for config. YAML can be employed as a simple JSON-like language with comments.

> simple

YAML is much, much more complicated than JSON.

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

#218

Post by crooked-v »

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…

Ansible would be so, so much better if it just used plain JSON, or even JS with an implied context for variables, .eslintrc.js style.

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

#219

Post by Edmond »

chc wrote: post #157
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.

YAML and JSON already represent object graphs. This appears to be essentially a config file editor, not a superior configuration format. It has a GUI for creating or editing a config, and then it outputs YAML or JSON or XML.

It can be hard to fully convey how ConfigNode works without actually showing it in action. Yes it does give you a UI environment to edit the object graph and outputs YAML/JSON/XML..etc.

However the output comes after evaluating the object graph. In other words it doesn't just reassemble a bunch of static values but rather actually executes objects (think POJOs) to produce the fields that make up each object.

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

#220

Post by derefr »

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.

You can use arbitrary tools to programmatically generate YAML (or JSON, or XML, any of the other "data only" formats.) This allows for tools to drive other tools by generating a spec file and feeding it in. See e.g. Kubernetes for a good example of that.

There's no language that I'm aware of that can natively generate PHP syntax, and there's no common multi-language-platform library for generating PHP syntax. I think that's most of the reason.

To contradict myself, though: Ruby encodes Gemfiles and Rakefiles as Ruby syntax. And Elixir encodes Mixfiles, Mix.Config files, Distillery release-config files, and a bunch of other common data formats as Elixir syntax.

And, of course, pretty much every Lisp just serializes the sexpr representation of the live config for its config format (which means that, frequently, a lot of Lisp runs code at VM-bootstrap time, because people write Turing-complete config files.)

Post reply on HN