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.
Why are we templating YAML?
311–320 of 351 posts
Re: Why are we templating YAML?
#312YAML 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.…
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?
#313Earlier 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.
Re: Why are we templating YAML?
#314As 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/
Re: Why are we templating YAML?
#315I 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…
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?
#316Earlier 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).
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?
#317Earlier 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?
Re: Why are we templating YAML?
#318My 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 already have to do that, so why not do it in a reasonably powerful language?
Re: Why are we templating YAML?
#319Earlier 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?
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?
#320I 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.