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

351–360 of 412 posts

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

#351

Post by Carpetsmoker »

foo101 wrote: post #301
arp242 wrote: 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.

> Last time I checked my domain got penalized for having abnormal low markup or some such Do you have a link to the document you were pointed to when you got penalized? If it was Google who penalized you, they must have pointed you to a URL with documentation on why you got penalized and how to resolve it. I ask this because I run a few websites with even lesser markup than your site but I have never got penalized. I…

I think it was some tool at moz.com, but I don't recall from the top of my head. I don't think it was Google itself. I have no idea what effect that has; I'm not really in to that world.

> I have had no issues with even lesser markup and they still appear at the top of the list of results for relevant search terms.

It seems people are finding my site, whether or not it's being penalized. I mean, someone other than me posted it here, right?

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

#352

Post by organsnyder »

rocmcd wrote: post #114
organsnyder wrote: post #105

Earlier quoted context omitted.

Why not just ?

That's the age-old question, isn't it? Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.

I've seen some pretty messed up schemas in JSON and YAML, too.

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

#353

Post by adamkruszewski »

nojvek wrote: post #305
spankalee wrote: post #279

Earlier quoted context omitted.

JSON5 is also a great alternative: https://json5.org/ Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.

I really wished json5 would support optional commas as well. If you have a new line, no comma needed. So you can do [ 1 2 3 ] New lines used by humans, computers should do a good job as well.

It looks very like an s-expression. Maybe we should go back to Lisp for our data encoding? (and to our code when we are at it? ;))

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

#355

Post by raziel2p »

kakwa_ wrote: post #329
pabl0rg wrote: post #314

Earlier quoted context omitted.

It is particularly unfortunate that ansible uses yaml because if infrastructure is going to be code, some day you will surely want to refactor.

The trend of "stick together Yaml and a template engine, we have our DSL!" in CM sytems is a bit horrible. Ansible does make some efforts to limit jinja templating to variable substitution, but it's sill not that great, you have all kinds of weird stuff that can happen specially with colons. The worst one is saltstack, the resulting syntax is just atrocious and border line unreadable, I not a big fan of map.jinja fil…

The whole concept of templating language on top of YAML is suspect anyway, but I wish Salt had just gone with Mako as the default templating language. That way you could write plain Python in your templates and not have this horrible misuse of Jinja.

I also have come to agree that a DSL is the best solution, though Puppet's particular DSL is not a great example. Projects that re-implement the same thing from scratch like mgmt[1] are on the right track, but probably won't gain enough traction.

[1] https://github.com/purpleidea/mgmt/blob/master/docs/language...

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

#356

Post by alessioalex »

pacala wrote: post #300
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".

Try https://jsonnet.org/ . Supports comments, plus a handful of additional useful features.

Oh man, you just made my day. Comments, imports and mixins, I just had an 'evrika' moment.

P.S. You Romanian by any chance?

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

#358

Post by homero »

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 love json but despise the fact it doesn't support comments

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

#359

Post by patrec »

clarkevans wrote: post #259
crdoconnor wrote: post #252

Earlier quoted context omitted.

>Thanks for StrictYAML, I might just use it. Thanks, that's very flattering. > I'd keep nodes/anchors, since I think a graph model is underrated Well, you can create graph models without it (and I do) - you can just use string identifiers to identify nodes and let the application decide what that means. I always thought the intent behind nodes/anchors was not so much graph models but rather to take repetitive YAML an…

> I think that would cause surprise type conversions. YAML has traditionally been used as the basis of higher-level configuration files for particular applications. What I'm saying is that implicit typing should be permitted, but delegated to those applications. Conversely, I'm not saying that StrictYAML should do anything by default with unquoted values, except reporting them to the application as being an unquoted…

An interesting idea, but it's not clear that this will be less confusing or that application authors will make better at avoiding config languages gotchas than config language designers such as yourself (and existing app specific config languages suggest otherwise).

I think a reason this won't necessarily fix the problem with unmet expectations is that identical constructs in different but analogous yaml files would be likely to end up with very different semantics and users effectively have to remember which particular idiosyncratic YAML dialect choices various apps make. Say

   version: 1.3
means the string "1.3" in app a), the float 1.3 in app b) and a version number in app c) one. Furthermore let's assume that app c) required a version number, whereas a) and b) required strings.

Another, more subtle problem, is that such a scheme would make it more likely that applications would end up parsing raw string representations themselves (with ensuing subtle differences even for things which are nominally meant to be identical, say dates or numbers and possibly security problems as well).

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

#360

Post by JdeBP »

scrollaway wrote: post #284
wwweston wrote: post #256

Earlier quoted context omitted.

> There's no language that I'm aware of that can natively generate PHP syntax This is a solid argument against using PHP (or any such language) as a cross-language data interchange format. There are others :) And I totally agree you want a language independent format for anything you might have to feed across an ecosystem of tools. For a PHP-system generating/altering its own config files... PHP's `var_export` genera…

You don't know when you'll need to generate or parse your config files with something that either can't read, write or execute your language. Django's settings.py sucks. I've used Django since the 0.9 days. It's extremely impractical and needs to be worked around constantly.

This, and the security problems of executable code as configuration, are why the OpenBSD people mandate that /etc/rc.conf is not general-purpose shell script, and why the systemd people mandate that /etc/os-release is similarly not. People want to be able to parse configuration files like this with something other than fully-fledged shell language interpreters; and they want these things to not be vectors for command injections.

* https://unix.stackexchange.com/a/433245/5132

Post reply on HN