Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

271–280 of 412 posts

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

#271
post #226

Earlier quoted context omitted.

Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.

Penalised? By whom?

The only search engine in town. You already know its name.

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

#272
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 it's just in general incredibly short sighted to think that your config file is never going to be read by code written in another language.

There's also an argument about whether making configuration files able to execute arbitrary code is a good idea. You get straight into the JavaScript 'eval' problems which we've spent a decade escaping.

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

#273
post #74

Earlier quoted context omitted.

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

Most parsers will not support JSON5.

More like browsers can de-serialize JSON5 natively. writing a JSON5 parser is not difficult. It's just not part of most std libs in most languages, but I would argue that most std libs don't parse YAML either.

JSON5 is a good compromise.

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

#274

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…

Unity3D uses YAML for it's serialization engine. Thank you.

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

#275

I am sad that EDN hasn’t achieved popularity as a format. It seems like a better specified, less verbose format. As a bonus it plays well with Paredit-like editor modes. Alas, the curse of being better, but later.

EDN is nice, but the curly brackets are a hassle when editing configs. That's why I prefer using yaml to configure my Clojure apps.

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

#276

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…

[deleted]

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

#277
We recently published a paper suggesting an alternative to HDF5 [1] using directories for objects, YAML for metadata and NumPy for data. Many of the points in this article were raised by the reviwers or were worries we had about choosing YAML as the metadata format. In the end, we decided to use a subset of YAML with only basic tags, enforced quoted strings, no directives, and no block scalar styles (fancy multiline strings). So far it has worked out great. I hope it will make the format easier to understand for users and make it possible to write faster parsers in the future.

[1] Shameless plug: https://www.frontiersin.org/articles/10.3389/fninf.2018.0001...

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

#278

Earlier quoted context omitted.

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

As someone who doesn't really use YAML much, your comment provides a good introduction to the kinds of things one needs to know before choosing formats in the future.

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

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

JSON5 is also a great alternative: https://json5.org/

Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.

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

#280
post #97

Earlier quoted context omitted.

> Douglas Crockford originally specified the JSON format in the early 2000s

> I discovered JSON. I do not claim to have invented JSON because it already existed in nature. What I did was I found it, I named it, I described how it was useful. I don’t claim to be the first person to have discovered it. I know that there are other people who discovered it, at least, a year before I did. The earliest occurrence I found was there was someone at Netscape who was using JavaScript array literals for…

I can independently confirm that people were using JSON before he named it JSON. I was dumping data in JSON in 2000 for dynamically displayed reports.

But then again I was already used to using Perl data structures as dumped by Data::Dumper for config, because I was taught a lot about Perl by a Lisp programmer who had used Lisp data structures for the same purpose since the 1980s. So using JSON didn't feel original or clever. It seemed like I was simply using a well-known technique in yet another dynamic language.

Then again our reaction to XML was the stupid thing other people were doing that you had to do to interact with the rest of the world. I got used to holding my tongue until I went to Google a decade later and found that my attitude was common wisdom there...

Post reply on HN