Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

321–330 of 667 posts

Re: Why are we templating YAML? (2019)

#321

Earlier quoted context omitted.

Indeed. I get a lot of value out of my strongly typed XML documents. I generally have code that validates them during writing and after reading. Those who don’t understand XML end up learning why it is verbose when they eventually add all of the features they need to whatever half-baked format they are using.

An XML document without a schema is strictly worse than JSON without a schema. JSON with a schema is strictly better than XML with a schema. XML structure does not map neatly into the data types you actually want to use. You do not want to use a tree of things with string attributes, all over your code. If you do have a schema, the first thing you will want to do is turn your data into native language data types. Aft…

> XML structure does not map neatly into the data types you actually want to use.

> After that point, the serialization method does not matter anymore, and XML would have just be slower.

Considering I have mapped 3D objects to (a lot of) C++ objects containing thousands of facets under 12ms incl. parsing, sanity checking, object creation, initialization and cross linking of said objects on last decade's hardware, I disagree with that sentiment.

Regarding your first point, even without a schema, an XML shows its structure and what it expects. So JSON feels its hacked together when compared to XML in terms of structure and expressiveness.

It's fine for serializing dark data where people won't see, but if eyes need to inspect it XML is way way more expressive by nature.

Heck, you even need to hack JSON for comments. C'mon :)

Re: Why are we templating YAML? (2019)

#322

Earlier quoted context omitted.

For code I'd agree. However for configuration files, I find that I often need to edit them in places or environments where I don't have anything but the most bare-bones editor.

A quick search shows that even nano can be configured to use whatever number of spaces you want when you hit tab: https://askubuntu.com/questions/40732/how-do-i-get-spaces-in...

I consider Nano a fully fledged editor. I'm talking Notepad or a html text box.

Re: Why are we templating YAML? (2019)

#323

Earlier quoted context omitted.

XML is more popular today than it's ever been. It's just called JSX now.

Besides being aesthetically similar to SGML, because it maps to HTML, JSX has nothing to do with XML. It is Javascript.

It just looks like JavaScript version of JSP to be honest.

Re: Why are we templating YAML? (2019)

#324
Ansible convinced me that doing programming tasks in YAML is insanity, so I started an experiment: What would Ansible be like if it's syntax were more like Python than YAML. https://github.com/linsomniac/uplaybook

I spent around 3 months over the holidays exploring that by implementing a "micro Ansible", I have a pretty solid tool that implements it, but haven't had much "seat time" with it: working on it rather than in it. But what I've done has convinced me that there are some benefits.

Re: Why are we templating YAML? (2019)

#325

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

> But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel

This is optional. Besides using a better parser that uses the spec that's long fixed a lot of these listed in the article, another way to avoid the issue is adding more verbosity (that would still not match XML nor JSON).

You don't have this option in XML/JSON, you can't remove all that useless markup (and leave it only when it's useful)

> Why is “on” a boolean literal

Because that's what humans use to denote booleans

Re: Why are we templating YAML? (2019)

#326
The problem is very specifically the fact that YAML, as a config language, sucks.

I have no idea why people started using it. "bUt jSOn dOeSn'T HaVe cOmMenTS" ... oh gimme a break! You want a comment in JSON?

    {
      "//": "This is a comment explaining key1.",
      "key1": "value1",
      "//": "This is a comment explaining key2.",
      "key2": "value2"
    }
There. Not so hard. Writing a config parser that just ignores all keys starting with "//" is trivially easy...if it's necessary to ignore them at all that is, because most config parsers I have seen couldn't care less about unknown keys, let alone repeated keys.

So what other "reasons" were there for YAML?

Oh, the human readbility thing. Yeah. Because syntactically relevant whitespace is such a joy in a data serialization format. It's bad enough when a programming language does that (and I am saying this as someone who likes python), but a serialization format? Who thought that would make things easier?

And then of course there are other things filled with joy and happiness...like the multiple ways to write "true" and "false", because that's absolutely necessary for some reason.

"Oh but what about strict-yaml?!" I hear the apologies coming...great, so now I have the ambiguitiy of what parser is used on top of the difficulties introduced by the language itself. Amazing stuff. If that's the solution, then I'd rather not have the problem (aka. the language).

But despite all[1] these[2] problems[3] and more, YAML somehow became the goto language for configuring pretty much everything in DevOps, first in containerization, then in cloud, and everything in between. And as a result, we now have to make sure our config template parsers get whitespace right. Great.

So bottom line: The problem here is maybe 1/3 the complexity of config files and 2/3rd the fact that YAML should have never been used as a configuration format in the first place. It's benefits are too small, and it's quirks make too many problems for that role, outside of really trivial stuff like a throwaway Dockerfile.

Want config? Use JSON. And if you need something more "human friendly", use TOML.

[1]: https://github.com/cblp/yaml-sucks

[2]: https://changelog.com/posts/xml-better-than-yaml

[3]: https://noyaml.com/

Re: Why are we templating YAML? (2019)

#327
The cycle seems: Invent a new static information format (XML/JSON/HTML/...), reduce verbosity, add GUI, variables, comments, expressions, control flow, validation, transformation, static typing, compilers, IDE support, dependency management, and maybe a non-backwards-compatible major version etc. And you end up with yet another Java/C# clone, just inferior because it was never meant to support all these things.

Re: Why are we templating YAML? (2019)

#328
post #51

Earlier quoted context omitted.

maybe yaml should standardise hygienic macros. and a repl.

The lengths people go to avoid using s-expressions never ceases to amaze me. We're talking countless centuries and great many minds pushed to brink of madness, just to keep the configs looking like Python or JavaScript.

I'd say it's even worse: it's a collective hallucination that complex configs are not code.

Re: Why are we templating YAML? (2019)

#329

Earlier quoted context omitted.

A quick search shows that even nano can be configured to use whatever number of spaces you want when you hit tab: https://askubuntu.com/questions/40732/how-do-i-get-spaces-in...

I consider Nano a fully fledged editor. I'm talking Notepad or a html text box.

Oh. Windows with no ability to install anything didn't even occur to me! I'm truly sorry.

Re: Why are we templating YAML? (2019)

#330
post #3

I am really sad that jsonnet / ksonnet never really took off. It’s a great way to template, but has a bit of a learning curve in my experience. I suspect that is why it’s niche. If you like what is presented in this article, take a look at Grafana Tanka ( https://tanka.dev ).

I was reading the description of Jsonnet and wondering why we don't just use JavaScript. Read a file, evaluate it, take the value of the last expression as the output, and blat it out as JSON.

The environment could be enriched with some handy functions for working with structures. They could just be normal JavaScript functions. For example, a version of Object.assign which understands that "key+" syntax in objects. Or a function which removes entries from arrays and objects if they have undefined values, making it easy to make entries conditional.

Those things are simple enough to write on demand that this might not even have to be a packaged tool. Just a thing you do with npm.

Post reply on HN