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

341–350 of 412 posts

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

#341

Post by Zardoz84 »

transfire wrote: post #330
arp242 wrote: post #197

Earlier quoted context omitted.

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

Actually it is even a superset of XML, from the docs... SDL documents are made up of Tags. A Tag contains * a name (if not present, the name "content" is used) * a namespace (optional) * 0 or more values (optional) * 0 or more attributes (optional) * 0 or more children (optional) So it's like an XML node, but the `0 or more values` means it has a list/array for a "body".

At least on the case of DLang implementation, uses a DOM api to access to the values. https://github.com/Abscissa/SDLang-D/blob/master/HOWTO.md

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

#342

Post by [deleted] »

krapp wrote: post #190
crooked-v wrote: post #4

I continue to hold a firm belief that the reason JSON is so popular is that it covers most use cases without any of the dumb crap that hides in YAML and XML behavior.

Yes. YAML and XML do way more than a config format needs. You need key value pairs and basic structures (variables, arrays and maps) and types. JSON is lacking in some respects but it's still really close to perfect for its use case.

[deleted]

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

#343

Post by drodgers »

crooked-v wrote: post #4

I continue to hold a firm belief that the reason JSON is so popular is that it covers most use cases without any of the dumb crap that hides in YAML and XML behavior.

Lack of comments, (nice) multiline strings and trailing-comma support make JSON a real pain for config in practice. I've started using YAML parsers for all of our (once) JSON config files, just to get those features (while preserving the curly-braces, commas, and other JSON-isms). Yes it allows a misguided dev to abuse YAML (mis-)features, but a combination of coding standards and linters can fix that.

Being a super-set of JSON is YAML's best feature.

I would never consider it for untrusted input though.

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

#344

Post by Sean1708 »

kakwa_ wrote: post #327
wwweston wrote: post #204

Earlier quoted context omitted.

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.

Using includes/imports is not the greatest idea ever. Your configuration file is one of your program interface. It's something that must be well define. If your configuration file is a programing language this interface is not that well defined. Also you expose yourself to all kind of weird bugs because some (too smart for their own good) people will monkey patch your software using it. It adds a lot of unnecessary s…

> If your configuration file is a programing language this interface is not that well defined.

While I do agree with the rest of your comment I don't think they were advocating using the full language for configuration, just the maps/arrays/etc. (e.g. Python's `literal_eval`).

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

#345

Post by continuational »

emodendroket wrote: post #137
tlb wrote: post #74

Earlier quoted context omitted.

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

If you're going to do this kind of thing why would you not add a standard date format

Just use a string and ISO 8601? “2018-03-25”

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

#346

Post by rusk »

I came in here to rant that YAML isn't for the same purpose as JSON and XML but then thought I'd better RTFA and realised that oh yeah one or two good points here.

The first criticism, where he's embedding exectutable code in YAML I kind of have to agree with - that seems crazy. I don't know why YAML would support this.

The remaining criticisms seem to relate to (a) the spec overreaching in terms of complexity and (b) differences in implementation, which I guess is some kind of an extension of (a).

I maintain however that YAML, JSON and XML are different.

If you want to make me feel cross and insulted give me a JSON file to edit. I think JSON is probably the best commonly used format for M2M and storage serialisation.

I wouldn't want you to use YAML for that though. There's two many different ways to do it and any kind of ambiguity never makes for good M2M.

For configuration-files it's great though, as long as you stay away from some of the more exotic features I suppose. It effectively provides a "user interface" of sorts by which your users can specify non-trivial configuration details.

The complaints about overlong and overcomplex yaml files could be extended to other commonly used formats.

With regards to XML, I'd say that YAML provides all the features you'd want to use from that format in a format that's easier to hand-edit as text. XML is "okay" for M2M but probably better for document storage where you have some kind of custom editor.

It's horses for courses. I wouldn't want to use YAML where I'd want to use JSON, or use XML where I'd use either of them, and neither of these have the semantic richness of XML either and so wouldn't be appropriate in whatever spaces XML should be used (which is far more limited I suspect than its current span of applications).

Ultimately when each is used to its strengths they're not interchangeable formats.

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

#347

Post by veli_joza »

clarkevans wrote: post #211
crdoconnor wrote: post #194

Earlier quoted context omitted.

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

Great to have you here elaborating on various design choices. Are you perhaps familiar with OGDL [1] and what's your opinion?

[1] http://ogdl.org/spec

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

#348

Post by koffiezet »

crooked-v wrote: post #218
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.

You can, but you lose the possibility of comments, and writing JSON by hand is also a pain in the ass...

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

#349

Post by aepiepaey »

DonHopkins wrote: post #255
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".

I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. The…

> YAML suffers from the same problem as JSON that it can't round-trip comments like XML can, [...]

While not mandated by the YAML specification, it doesn't prevent creation of a parser that round-trips comments.

In fact, the ruamel.yaml project for Python provides one.

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

#350

Post by aepiepaey »

bhaak wrote: post #40
ChrisSD wrote: post #5

I agree with some of the author's points but the "surprising behaviour" section is odd. For example, why would you expect `3.5.3` to be parsed as a number? How could that be parsed as a number?

The 013 to 11 issue is pretty obvious to any seasoned programmer. For example C, Ruby, and yes, also Javascript have the same "problem". Octal 13 is decimal 11. JSON should actually have the same issue. When I enter { 013: "11" } in the web console I get '{11: "11"}'. And YAML is backwards compatible to JSON. That's IMO the actual problem of YAML. It could have supported a reasonable subset of JSON and not the whole…

The web console is not a JSON parser. To check if something parses as JSON in the web console you should use JSON.parse, e.g:

  JSON.parse('{ 013: "11" }')
which should produce a syntax error (as already mentioned by siblings to this comment).
Post reply on HN