Live data from Hacker News

Why are we templating YAML?

leebriggs.co.uk

311–320 of 351 posts

Re: Why are we templating YAML?

#311

Earlier quoted context omitted.

XML is not tedious at all with the right tooling. For example a tool like Visual Studio IntelliSense proposes only elements and attributes valid in the context, automatically close tag, format the file and complete opening tags too so it makes editing XML file a breath.

The tooling bar for config files is set firmly at notepad.exe If your config file requires more tooling than that you fucked up.

notepad is a terrible editor for anything other than simple property files. For example, editing JSON that has any sort of complexity would be just as painful.

Re: Why are we templating YAML?

#312

YAML is a data stream, not a program. Please do not shove programs into data. Your data does not need to be "expressive", it just needs to provide input to a program. If your data files need to be complex, you need a program to generate them for you. I've danced the dance of ini -> json -> yaml -> weird hybrid -> embedded logic, and it ends with "program that asks for what the thing you want looks like and generates…

And you end up with program compiled to a config anyway, so with a proper toolchain it means your real config is the program. People keep increasing complexity unintentionally precisely because they don't realize that code = data . There's no real distinction. Code is data is code. You will end up having Turing completeness somewhere , it's just a matter of choosing (or blindly selecting, like most people do) where.…

"Data" to me is the least complex input from a human, whereas "code" is more complex and necessitates a lot more work to make sure it's correct and bug-free.

If you embed "code" in "data", you made your thing way more complex and subject to software design patterns. But in software operation, we already have to contend with highly complex systems, so we want to remove as much time and effort and complexity as possible from the instrumentation.

To put it another way: if you had to run a nuclear reactor, do you want to instrument it by constantly writing new code, or turning a dial? I'd rather turn a dial. That means I have to develop the code for that dial ahead of time, but in the end, actually using it will be safer.

Re: Why are we templating YAML?

#313
post #124

Earlier quoted context omitted.

Tools keep using it even where it's the wrong tool for the job, so someone must like it, surely? I'm sure it will be just like XML where it's the trendy thing for a while in the early days, then everyone stops and hates it for a while. Except XML at least has a handful of applications where it's the right tool for the job (it has a nice streaming mode), YAML doesn't even have that.

YAML is great for simple human-editable configuration files. Its very easy to write, and can be picked up quite quickly. Opting for YAML over XML/JSON/whatever doesn't make me a tool. It made life much easier for myself & my colleagues.

heh, I didn't even consider this interpretation of the above; sorry about that. I meant "tools like Docker keep using it", not people. But I still don't know what you're talking about; YAML has an 83 page spec that includes pointers, and uses tons of random confusing symbols. I say "maybe it's just me" in some of these posts, but I know it's not: I've watched many of my coworkers get it wrong the first time for years and then have to be corrected. A quick common example I see in CI config all the time: If I write version: 1.10, that's a number, then I decide to move to latest so I write version: 1.10.x, that's a string. Oops, we were never using version "1.10" we were using "1.1". Everything about it is implicit and bad. Now, it's easy to say "always use quoted strings", and I agree, but then why the hell does it have bare strings in the first place? That seems like an easy enough oversight or typo to make, and it will be made.

Re: Why are we templating YAML?

#314

As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than XML for config files, and it doesn't even have the nice streaming mode. Not to mention that it's a bit of a security nightmare (seriously, who put pointers into the YAML spec?). And, on a more subjective note, YAML is just confusing: between all the significant…

If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

I end up hitting bare string implicit casting problems constantly. I also end up catching them in code review when codeworkers do it constantly and yet I still end up doing it too. This might be the best example of why YAML is overengineered garbage (that and the fact that the spec is 83 pages long and has pointers… WTF?).

Re: Why are we templating YAML?

#315

I know I'm in a minority, but I really dislike YAML... I recently did a lot of Ansible and boy, at the beginning, I was just struggling a lot. Syntactic whitespace kills me. I don't like it in Python either, but for some reason, when I write Python, it's a lot easier. Maybe YAML is just a bit more complex (and Python has better IDE support..?)

> Syntactic whitespace kills me. Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages. Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant…

I largely agree with you, but:

How hard is it to use HN formatting? I can’t count how many times people screw it up.

It’s not difficult to begin with, the documentation is free, yet here I am reading your comment with broken formatting.

    something: nothing
      hello: goodbye
Anyone who has trouble with this is just being sloppy. No useless backticks! You might think you’re doing it right, but unless you check, maybe you’re not.

Re: Why are we templating YAML?

#316
post #161

Earlier quoted context omitted.

Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?

You can always use a subset of YAML (much like we do with JavaScript these days).

That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky behavior that can be abused too like pointers).

Using a subset creates more work for the developer, so many just won't bother (if they even know that it's using a subset and they have to do more work at all), which leads to issues.

Re: Why are we templating YAML?

#317
post #161
post #157

Earlier quoted context omitted.

God, I hate programming some times.

Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?

Unfortunately, this isn't practical. For any of my own tools I will never use YAML, but I don't just use my own tools, and reinventing the wheel just to not use YAML has its own problems which are (in some cases) worse.

Re: Why are we templating YAML?

#318
post #198

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…

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff? Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?) Dhall solves exac…

> you have to refactor and maintain it

You already have to do that, so why not do it in a reasonably powerful language?

Re: Why are we templating YAML?

#319
post #198

Earlier quoted context omitted.

This is a great analysis, but it's missing a fundamental point: why do we have a problem with these approximations of a programming language or just using a programming language to template stuff? Because your build then becomes an actual program (i.e. Turing complete) and you have to refactor and maintain it! This is the common problem of using a "programming language as configuration" (e.g. gulp?) Dhall solves exac…

> you have to refactor and maintain it You already have to do that, so why not do it in a reasonably powerful language?

Here's a nice explanation on why using "reasonably powerful languages" has many disadvantages: https://github.com/dhall-lang/dhall-lang/wiki/Safety-guarant...

Also you might be familiar with the Rule of Least Power: https://en.wikipedia.org/wiki/Rule_of_least_power

Re: Why are we templating YAML?

#320
I feel like Ansible generating YAML with Jinja templates is really a sweet-spot, with idempotency and reusability.

I find it pushes me to write plain YAML files for variables and defaults (Ansible), while allowing strong templating of generated files (Jinja) and letting the result be readable (YAML). By readable I mean minimum programming bloat (code spread on many lines just to write a for loop) and minimum extra syntax that clutters the screen (brackets and quotes). It also lets me write very little custom code (aside from variables, obviously).

If I had to use a more "powerful" YAML-like replacement, it would mix all these into files, written differently by people with different styles, and it would have bloat all over the place.

The main issue I have with helm is that values.yml is not templatable by default so you have to generate it if you want reusability.

YAML does one thing and does it well, it's readable and bloat-free. Maybe we need more tools like "kubectl explain" to know the syntax though.

Post reply on HN