I tell people I'm a software engineer but in reality I'm a config file engineer
this post was submitted on 12 Nov 2023
751 points (96.6% liked)
Programmer Humor
19512 readers
337 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
Senior YAML programmer
Careers Fair; 2024
Teen: “Excuse me; how do I become a Tech Lead like you someday” Lead: “By simple luck of the draw I am the best at googling other people’s solutions to my team’s YAML config issues.”
Eh. Software is just data too. It's about solving problems with systems using those systems and other systems and that's software engineering. It's recursive and wherever you are in the stack you're standing on the shoulders of giants, and you're still doing engineering. 💪
Lol. Legitimately.
Did you know YAML is a recursive acronym? It stands for 'YAML AML MAML LAML'
Nature is beautiful❤️
Is it polynomially recursive? Like, the AML stands for "AML MAML LAML", and so on?
YAML would such a nice language for config files but then it turns out that "no" is falsy and so a list of Scandinavian countries turns from
- se
- fi
- no
into
- "se"
- "fi"
- False
I wish there was like a JSON5 equivalent for YAML that just reduces its scope lol
(and no, TOML also looks ugly :P)
Norway is false and Finland isn't in Scandinavia
S W E D E N
S W E D E N
S W E D E N
This is definitely a failing of yaml. Though, I feel that generally it's the sort of thing you learn once the hard way, then it sticks with you pretty well.
Also I'm glad there are more anti-toml folks are out there, feels like I'm taking crazy pills when people say it is "simple" and "elegant". IMO it's uglier than old-school ini format - at least it's more strictly defined but that doesn't really sway me to convert
Which is better for structured data?
- elegant, human readable, indentation sensitive language that's great for deep nesting but has some weird idiosyncrasies with some dynamically typed parsers being too smart for their own good
- glorified ini
The choice is clear
TOML isn't elegant at all but damn, it is really simple.
If by simple you mean "can't count from 1 to 10 in a loop" and by elegant you mean "easier to understand than a one line perl script" then sure...
You're looking for StrictYaml
Looks interesting, I'll check it out, thanks :D
Ansible go brrrr
... slowly.
And yet its faster, easier and more reliable in setting up and maintaining complex cluster software.
Could've been worse. Could be unprettified json.
Json is incredibly easy to prettify.
I do it by converting to yaml ;)
I wrote a json prettifier a couple months ago with just a couple lines of code. I thought it would take a while but ended up taking like 10 minutes.
js's JSON.stringify(obj, null, 2);
Import json Import pprint?
| jq
| jq
I use jq pretty much every day
You know, at this point I've been writing YAML on and off for a while now. You'd think I actually understand the syntax by now, but I don't.
That's because it is absolutely terrible. It is the first serious/real "language" I have encountered since Cobol where indent level has functional meaning. This is not good company to be in.
The python community would like to have a word with you.
Python has stricter rules about what can be cludged together and how.
Yaml is... Kind of nebulous, which is not a good thing for a data serialization format.
Yeah not a fan of YAML either. I simply don't see the benefit of getting rid of delimiters and replacing them with indentation. Yes, it does save several bytes, which might be important if you measure space in kilobytes I guess. It does provide cleaner files which may or may not be more readable.
It does not provide any advantages in parsing complexity. It does not provide any protection against typos.
I guess the same can be said of python, which forces indentation and therefore readable code formatting. Which is a problem that does not exist since the invention of code formatters and linters.
I like python for what it does but delimiters are actually useful in terms of readability. They provide an extra hint that the text you're about to look at conforms to a specific structure.
Oh god, parsing complexity. I actually tried writing a YAML parser in my free time before and boy was that not worth the headache. So many little things that complicate parsing and are ignored by majority of users!
I really like python, but I can agree that it's no-delimiters style can be... Confusing at times. I definitely had to hunt down bugs that were introduced by wrong indentation. That and the way it handles global/local variables, mostly.
I do appreciate not having to enclose every key in "", and being able to copy values - but if we want that kind of logic making our configs, why not just switch to writing configurations in Lua? It certainly has less footguns than YAML and it has the niceties like "I can just write {key = "value"} instead of {"key": "value"}".
Honestly that probably goes for any interpreted programming language that supports imports.
Many Javascript frameworks just put their configuration into -.config.js files in the project root. Which is a pretty elegant solution that does not require custom parsing. Just import the config and go nuts.
Compiled (and by extension bundled) software obviously requires a different approach, but at that point you should probably consider storing your config in some kind of database.
Maybe there just isn't a right answer to the config conundrum if all the general solutions are janky in some way.
Well, there's a few things I personally think are a must for a config format:
- It must be human readable and editable, in some way. - in many cases, you may want to go and change something in the config while the application proper isn't running. That rules out stuff like pickle or binary formats. Although I suppose sqlite and it's ilk still fulfill it, in a roundabout way.
- It should be unambiguous, with one way to do something right. - this one's a doozie. JSON fulfills it since it's unambiguous about it's types, but many interpreted language configs will have options. And then YAML will have "no" turn into "false".
- It should probably have comments. - handily failed by standard JSON implementations. Although to be fair a lot of parsers I've used understand comments. Or you can make a comment stripper real easily.
- It should have obvious structure. - I've dealt with CSV configs before, I do not want to ever again.
Me carrying a comically oversized box of compose files.
Fucking hate YAML. With every fibre of my being. YAML needs tO GTFO
Nix
Nothing
I didn't know that ansible-galaxy had a comic
In typical ansible fashion, expect it in 20 years.
My fatass read a box of donuts
Those devops should switch to nix already 😁
A fun YAML fact is that it’s a superset of JSON. All JSON is valid YAML.
Not sure, how much fun there is in that fact