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

201–210 of 412 posts

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

#201

Post by jiveturkey »

chx wrote: post #187
mottosso wrote: post #179

Earlier quoted context omitted.

Ok, I'll bite. { "#": "A foo variable", "foo": true, "#": "A bar variable", "bar": false } Alternatively. { "# A foo variable": "", "foo": true, "# A multiline..": "", "# .. bar variable": "", "bar": false } Presto!

Sigh. All I wanted to do is to say thanks for the YAML standard -- comments are important but not the only problem with JSON. And truly I can't be expected to remember all of this discussion from like six plus years ago. One thing I remember though, it the trailing comma problem -- we upstreamed a grammar change to Doctrine annotation so "foo, bar," is OK because PHP arrays accept that and it's bonkers trying to code…

fair enough, but then you probably shouldn't have led off your earlier comment with "that simple".

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

#202

Post by goatlover »

mottosso wrote: post #179
dharmab wrote: post #165

Earlier quoted context omitted.

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

Ok, I'll bite. { "#": "A foo variable", "foo": true, "#": "A bar variable", "bar": false } Alternatively. { "# A foo variable": "", "foo": true, "# A multiline..": "", "# .. bar variable": "", "bar": false } Presto!

That's just ugly and you're mixing your comments with the data structure, which is potentially confusing. Also, Jason requires a lot more typing. I don't want to have to manually add in all the brackets, quotes and commas when editing config a file.

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

#203

Post by Carpetsmoker »

kevinmgranger wrote: post #38

> Can be hard to edit, especially for large files How does this entire section not also apply to JSON?

JSON is slightly easier since you have actual start/stop marks in the form of `{`, `}`, instead of relying on 2-space indentation. (are there 8 or 10 spaces there? Hard to see).

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

#204

Post by wwweston »

chx wrote: post #63
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…

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.

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

#205

Post by freedomben »

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…

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

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

#206

Post by sandov »

arp242 wrote: post #191
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…

I am the author of this article. Apparently people read my website (how they get there, I don't know?) At any rate, it's worth mentioning that in the conclusion I wrote: > Don’t get me wrong, it’s not like YAML is absolutely terrible but it’s not exactly great either. I still use YAML myself even when I have the freedom to use something else simply because – for better or worse – it's very widespread, and for many ta…

I love the clean style of your website.

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

#207

Post by irascible »

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.

Because code injection.

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

#208

Post by wruza »

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.

Trees are not graphs. You have to un-circularize your objects before stringifying.

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

#209

Post by viraptor »

Zardoz84 wrote: post #148

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 don't get the matrix example. Why is it different from key 1 with multiple values 0, 0, and key 0 with values either 1, 0 or 0, 1?
Post reply on HN