Hacker News Reader

Comment by zelphirkalt | Hacker News Reader

> [...] If it was that bad, nobody would use it.

Haha, if that logic held true ... we wouldn't be using lots of things.

Usually people use things, because "that's how we have done it before" or "that's all we know". Not many people look for better tools frequently. They try to get something done and the moment it is working, they are done with it. People are frequently punished for trying to improve the current state, by management that tells them: "But it already works! No business value in changing it now."

View on HN

You forgot "that's the only viable option provided by the vendor." Some people are reliant on certain software as a requirement and forced into certain standards imposed on them. They don't exactly choose the standard, they have a functional requirement and the only way to achieve it in some budget/timeline may be with a third party solution that uses, say YAML.

Yeah I've been there personally too. But why aren't we complaining about the vendor then?

I find it weird that we love to complain about the YAML format instead of the projects that chose it. Given some of the emotions I saw in other responses in this thread, it looks more like a venting exercise.

Which is fine, I guess. I was simply curious on why suddenly it got propped up again.

If ten thousand vendors use one subpar language, it makes sense to try to swing opinion away from the language, rather than play whackamole with eleven thousand vendors.

because the complaint is with yaml.

Just use JSON then?

Config needs comments

Use json5 ?

I use CUE, it is awesome and a joy to use

For some reason that line triggered a lot of folks. That was not my intention, haha.

I agree that it's not always under our control and that can be extremely frustrating. But that's not YAML's fault, is it?

When I wrote "that bad" I truly meant the extreme version. Something so bad that it has no upsides. Which IMO is not the case here. YAML has pros and cons, just like all others, and for one reason or another many folks in several different projects decided that YAML was a good enough choice.

I have a very hard time assuming everyone that ever chose YAML is so incompetent that they never thought about the pros/cons of it.

There's always a tool that will work better for a specific use-case, especially when you either don't understand or have forgotten about some of the requirements.

Well the question about business value is a good one, no? After all, the question is not "Would improving this thing be a good thing?" it's "Would improving this thing be better than every single other thing we could be doing with those same resources?".

Besides there's an equal and opposite danger with too much change or change delivered without clear benefits. I'd prefer a 7/10 UI which stayed the same for a few years vs a 8/10 UI which changes substantially every month.

Here's the thing. We've basically been using TOML since the INI file format from MS-DOS. It works, and it's useable, and we've all seen it. TOML is just an evolution of the INI format to fix some of its shortcomings. YAML blasts onto the scene like "hey, what if we just rewrite the JSON format to make it legible?" which brings with it a million edge cases of problems.

YAML is the new kid on the block. And despite having several great formats for different use cases already, some kind of mass hysteria caused big players to adopt YAML. I suspect everyone who adopted YAML is either a Python dev or they were drawn in by the legibility of the format. It's easy to read. While that's true, did anyone stop to think about what it's like to actually use the format?

> Usually people use things, because "that's how we have done it before" or "that's all we know".

You forgot "this is the sexy new shiny way to do it, let's hop on the bandwagon! The old things sux!"

Yeah, but you mention Rust one time and everyone gets mad ...

Not only do you get punished by management, but you get ridiculed on HN for trying to change the status quo!

Reply on news.ycombinator.com