Interesting. I’ve apparently never seen the original. The best version I’ve seen, which I thought was the original, was porn. It just makes the guy’s face in panel 4 that much better.
For a start, there’s no such thing as “YAML” so it’s not funny. If the ‘punchline’ is a random gibberish word that no one understands then it’s not funny. That’s generally the rule.
So I just looked it up, YAML is a programming language, that is “often used for writing configuration files.” Then I checked the group this was posted on, makes a lot more since now.
The UX for knowing in which community something has been posted in is not very good here, I feel a lot of people have problems getting the context if you don’t spell it out in the title.
How’s it annoying? It’s easier to edit by hand than json as it allows for comments and there’s no trailing comma errors. I prefer it any day over json.
It’s just another syntax to learn. For someone who already has their head crammed full of a bunch of other syntaxes over the years, I didn’t want to learn a new one. YAML has kind of forced it’s way in anyways though.
There’s a lot of foot guns in YAML. The specification is way more complicated with hidden obscurities. JSON specification is just 5 diagrams. YAML speciation on the other hand is an 86 page pdf, so there’s more room for nasty surprises (which is not a thing you want in configuration files).
I’ve also seen many people struggle more than they need to with the yaml indentation.
I think the only upside to yaml is that it allows for comments, but other than that JSON all the way.
not at all. it’s used for configuration and stuff. having a lot of it can be a real bummer depending on the context. like a puppet config or perhaps a super weird docker compose setup. I’ve never heard anyone complain about the markup though. it’s like blaming json for a crap api or something or idk blaming the coffee cup for burnt coffee 🤷
It’s just another structured data format. It’s used for a lot more than config. It’s also how you define commands and etc for Ansible. Like how a Maven project is defined in XML or a NodeJS package has its JSON.
Sure they’re still “just” data formats on their own, but what they’re used for is genuinely just as important as what it is. I really doubt XML would’ve held on like it has without HTML being the web.
For some little config it’s fine, but it’s horrible when used when you have thousands upon thousands of lines of it. Lots of DevOps tools tend to use it like a fully-blown turing-complete programming language, and each has a different DSL of doing variables, loops etc. And that becomes an abomination.
I honestly think that JSON and YAML should be swapped due to YAML’s strict indentation rules whereas you can just pack an entire JSON object on one line.
Oh this is a good point - the syntax error on line one has ruined several productive days.
Of course the tool would happily prettify it for me, but it has to be valid json. Which I think would make it more enjoyable if it said in that message “Good luck, we’re counting on you.”
I think yaml’s need for indentation alone makes it chaotic evil. I’ve seen so many people struggle with the indentation than they really need to it’s not fun. Especially problematic with large configuration files.
JSON is easy to unpack with tools like jq or whatever.
There are 6 different combinations of “interpret multiline whitespace” character patterns. There are three types of single-line strings, and if you use “Yes” or “No” the data gets type cast.
Just because there are a lot of rules doesn’t make something chaotic in this system. The lawful-chaotic axis is a spectrum of how much of a stickler for the rules you are. YAML’s “one whitespace out of place and your whole config is fucked” attitude puts it squarely into lawful territory. JSON by contrast gives no shits about your file structure as long as your curly braces match.
I just learned yesterday you can do this, lol. You can use “//”: ‘’ once at the root level of a package.json file.
Had to put an override to block a dependency of a dependency from installing (@types/* stubs when the package now has native type defs that conflicted with the no longer maintained stubs).
Also where’s regex? Though that’s so troublesome because it’s a process encoded in a string, not really a structure with debatably obnoxious syntax… hmm
There are plugins that go back and forth between JSON and YAML so as you might expect it’s similar. Unlike JSON, spacing has semantic meaning, which can be a little annoying, especially when cutting and pasting. It’s nice in that configs aren’t cluttered up with open and close braces. It could be annoying AF if you’re a tabs instead of spaces person but idk because I’m a spaces person.
I like YAML for config over .config files but it’s not a big deal either way. It just encourages better organization of settings because the hierarchical structure demands it while .config let’s you just drop a setting anywhere in the file. But it’s valid to have the opposite preference for the exact same reasons.
The problem is that the current fashion of devops is done through piles and piles of badly defined YAML. If it used any other configuration language, it would be just as bad.
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. 💪
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.”
That’s more of a weakness of yaml. There’s so many ways to specify the exact same thing. Not exactly what you need for configuration files maintained by multiple people. It easily becomes an big incoherent mess.
In JSON the default way is the only way. Nice and coherent.
I agree that YAML is painful and it really seems like it’s had a lot of feature creep.
JSON is painful in its own way too, though. There’s a lot of syntax noise from things like braces, quotation marks, etc, so it’s easy to make a mistake. Regular JSON doesn’t allow trailing commas.
YAML tried to solve some of that, and did succeed in some ways, but introduced its own issues.
TOML seems great to me, but maybe it has its own issues. TOML actually has defined data formats for things like dates (both offset and local) and times, which is missing from both JSON and YAML so every app ends up doing it its own way.
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.
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.
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
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
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.