Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

91–100 of 351 posts

Re: Why are we templating YAML?

#91

The real question is why are we using yaml at all?

Easier to read and write than JSON. JSON requires constant quoting, can't support multiline strings, has no comments, has no/little typing (e.g., no datetime type). It's not good if a human needs to encode data. For configs, I think TOML beats YAML hands down; I think YAML's spot is at encoding data structures that humans need to read/write. I do agree that YAML, the spec, is fairly complicated. But YAML, as used in…

>For configs, I think TOML beats YAML hands down

If you compare a medium sized, 3 level deep TOML document with an equivalent YAML document you'll find that the TOML document is up to 50% longer.

None of that additional verbosity adds meaning - or readability.

Part of this is the extra syntactic noise but most of it is because all of the key names have to be defined explicitly above the key values for each value whereas in YAML you just need to put the values below an indent.

TOML is tolerable for small, very lightly nested config files but even medium sized TOML configurations get ugly very fast.

Re: Why are we templating YAML?

#92

The real question is why are we using yaml at all?

Baffles me. I don't like any language or file format where whitespace matters. Even Haskell bothers me in this regard. To me white space shouldn't add cognitive load. I want to look at the symbols not the formatting of the antisymbols to understand what is going on. Write JSON and use your editor tools to format it with nice indentation, and you are sweet! That said Yaml makes an excellent format for reading, but not…

> I don't like any language or file format where whitespace matters. .... To me white space shouldn't add cognitive load.

1. there is no language where whitespace does not matter

2. the very purpose of indentation is to ease cognitive load.

Now, you may not want it to be inflexible or mandatory but your argument needs elucidating.

Re: Why are we templating YAML?

#93
post #21
post #16

Earlier quoted context omitted.

I have the same experience. I just think think it is possible to design easy-to-write indentation-sensitive formats but YAML is not. For example is always baffles me that a: - b - c has a list inside an object but the list is not further indented. There's in fact a hierarchy relationship but absolutely no indentation.

You can indent it though, but the hyphen already means a list item. That is a preferred syntax for many that are used to YAML though.

FWIW, I think yaml / ansible linters and style checkers typically require indentation.

Re: Why are we templating YAML?

#94
post #25

Who knows. It makes me throw up a little in my mouth every time I see hundreds of lines of YAML to configure something like Traefik with Kubernetes. The worst is when people say they prefer that because "I don't have to write a config file for my backend". That's true but instead now you have extremely verbose configuration mixed in with other verbose configuration. But in YAML's defense I think it's more of a proble…

I agree that simple YAML can be nice as a quick and clean tool, but Ansible is an example of everything wrong with how YAML is used. Layering program flow constructs like loops, variables, templates, references etc. are exactly the sort of abuses that make YAML feel awkward.

Re: Why are we templating YAML?

#95

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

Are you going to add C# support?

Re: Why are we templating YAML?

#96
post #21
post #16

Earlier quoted context omitted.

I have the same experience. I just think think it is possible to design easy-to-write indentation-sensitive formats but YAML is not. For example is always baffles me that a: - b - c has a list inside an object but the list is not further indented. There's in fact a hierarchy relationship but absolutely no indentation.

You can indent it though, but the hyphen already means a list item. That is a preferred syntax for many that are used to YAML though.

The hyphen is associated with the a though. In what's posted, a is a list, not a map - the type of the parent is being declared by that hyphen.

Re: Why are we templating YAML?

#97

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

> My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years.

I think that you’re right, and I think it’s great, because we have a programming model in which code is data and data is code: Lisp & S-expressions.

It’d be downright awesome to have a Lisp-based system which used dynamic scoping to meld geographical & environmental (e.g. production/development) configuration items. But then, it’d be downright awesome if the world had seriously picked up Lisp in the 80s & 90s, and had spent the last twenty years innovating, rather than reïnventing the wheel, only this time square-shaped. But then, the same thing could be said about Plan 9 …

I’ve not yet had the time to take a look at Pulumi, but I hope to have time soon.

Re: Why are we templating YAML?

#98

Earlier quoted context omitted.

YAML is a bit bonkers in that it's a superset of JSON (all valid JSON is valid YAML), so if you don't like the whitespace sensitivity, you can write your YAML like this: { a: 42, # But you can have comments! b: "hello world", c: "and multi-line strings!", # and trailing commas! }

I wrote a pared down version of YAML because while I like the basic structure I hated the complicated bullshit like the "we also parse JSON" layered on top: https://github.com/crdoconnor/strictyaml Worse than JSON though, is the Norway problem. If you remove this stuff and start validating it properly it becomes much easier to maintain.

> the Norway problem

Huh:

https://hitchdev.com/strictyaml/why/implicit-typing-removed/

I've always liked YAML, it's always seemed pretty intuitive to me coming from Python, and I like human-readable resource files, but those are some pretty damning counterexamples.

Re: Why are we templating YAML?

#99
post #46

Earlier quoted context omitted.

No comments, constant need to quote every string, inane comma requirements, no multiline string, little typing support.

Many language require strings to be quoted, and calling the comma requirements inane is an opinion, not an objective fact. You're not saying anything about the readability of one versus another, you're just listing gripes you have about JSON.

You post a comment describing one alternative as "simpler" and "easier to read" compared to another.

Respondent lists five specific reasons in support of the opposite conclusion.

You dismiss those as "opinions, not objective facts". Ignoring that the same could be said for your parent comment, to a much greater degree.

Re: Why are we templating YAML?

#100

My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) p…

I think what you're doing with pulumi is the right answer and it's only a matter of time before this becomes the norm. The author's examples could easily be done with plain ol' JS/ES/TS with more far more extensibility and customization when the need arises.

I also feel this is where JSX got it right. Instead of creating yet-another-templating-language (looking at you Angular!), they used JavaScript and did a great job of outlining how interpolation works. Any new templating language is always going to be missing some key feature you expect out of a general programming language and your customers will continue to ask for more features.

Take for example Terraform and HCL, they're continually adding more and more [templating features](https://github.com/hashicorp/terraform/blob/master/website/d...) and [functions](https://www.terraform.io/docs/configuration/interpolation.ht...) because there's so many different ways to skin configuration/infrastructure as code. What if TF just expect a "computed" JSON object and it's left up to the developer to figure out how to put it together?

I'm gonna keep an eye on Pulumi and hope to be able to use in a real project soon.

Post reply on HN