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

191–200 of 412 posts

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

#191

Post by arp242 »

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 tasks it's "good enough". For other tasks, I prefer to avoid it.

I think that a stricter version of YAML (such as StrictYAML) would make a lot of people's lives easier though.

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

#192

Post by atom_arranger »

tajen wrote: post #180
0xbadcafebee wrote: post #85

Years ago I had to support a tool that used YAML as a configuration language, and a transport between different applications. Holy. Hell. First of all, don't ever try to edit a YAML file by hand. You will introduce whitespace or other characters that will break the file, and you will not know until you run it and it breaks something. The reason you will not know? Not all YAML parsers are the same. Some will interpret…

Well your last sentence is the whole point: What is a sensible configuration language? For example what would have been decent for Ansible?

A lot of JS tools now will just take a js file that exports a configuration object (`.prettierrc.js`, `.eslintrc.js`, `.babelrc.js`). I find it very sensible.

- Allows code reuse.

- Allows configuration to be as dynamic as you want.

- Can use environment variables.

I suppose there are some cases where you can't trust the user in this way (running configuration code), but I think in a lot of cases you can, and it's generally more convenient.

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

#193

Post by suresk »

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 get a lot of flak for this, but there are definitely times I miss XML for certain things and find it way easier to work with than JSON or YAML. I definitely understand some of the backlash against XML that happened a decade or so ago and definitely don't want to return to the days of half of a Java application being XML code.

I think JSON is more efficient to write, but XML often ends up being more efficient to read due to comments and the fact that XML tags often give you better context. I think most programmers (myself included) tend to heavily optimize towards writability when we should think about readability a little more.

An example of this is ElasticSearch, where your queries are in JSON and often end up tons of levels deep - it is super easy to get lost in a sea of closing brackets, whereas XML would let you add comments in and the fact that closing tags have names in them would give you better context about what you were doing.

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

#194

Post by crdoconnor »

clarkevans wrote: post #125
bhaak wrote: post #72

Earlier quoted context omitted.

> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?

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 designed. If you put two hierarchical documents side by side - one in TOML and another in YAML the YAML one is much, much clearer and cleaner.

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

#195

Post by benatkin »

merb wrote: post #171
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".

well there is also toml and hocon (json supersets) which are "yaml like"

TOML is more like ini than YAML.

I don't like it because it uses the = symbol which seems imperative rather than declarative. (Same with HCL, it might be a nitpick but these are languages I'm going to be using all the time.)

HOCON is interesting but at first glance it seems it might be too ambiguous for my tastes, because like YAML, because it supports both js-style ("//") and shell-style ("#") comments.

JSON plus comments is beautiful because it adds minimally to an unambiguous language which lends itself to automatic formatting (stringificiation).

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

#197

Post by arp242 »

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…

One thing I dislike about it at a glance is:

    author "Peter Parker" email="peter@example.org" active=true
This is like XML attributes, which I've always found annoying to deal with in programs. It doesn't really map to any native data structure in most (all?) programming languages, so you need a special class/struct which supports it.

Simply using something that maps directly to a hash map/object/associative array would be much better, IMHO.

Other than that, it looks like an interesting project.

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

#198

Post by Carpetsmoker »

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

This is ugly.

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

#199

Post by transfire »

One of the important things implementations failed to do was properly support Schemas (http://yaml.org/spec/1.2/spec.html#Schema). And this is still the case today. Had they done so, the safe load issue would never have arose, and the loaders/dumpers would be properly configurable to suit the needs of the application, e.g. don't support "Yes" and "No" as `true` and `false`.

I once did about 98% of the work to support Schemas properly in Psych (https://github.com/ruby/psych) but the maintainer said he didn't want to "maintain it".

So, there you go. What else can one do? You can't blame the spec for decisions of implementors.

(That's not to say the YAML spec couldn't use some improvements, but it's far from "not so great".)

Post reply on HN