Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML: Probably not so great after all

arp242.net

Post reply on HN
Print view View original

291–300 of 457 posts

Re: YAML: Probably not so great after all

#291

Post by matt_kantor »

Noumenon72 wrote: post #272
regecks wrote: post #206

Earlier quoted context omitted.

Why would they have chosen to use template/text to generate YAML? That seems insane. Surely using an encoder on an object/structure hierarchy (like people do with encoding/json) is the way to go? On the other hand, the quality of the yaml libraries in Go wasn't great, last time I had to choose a configuration file format.

What is "an encoder"? Like a function that takes the same variables as the template would but does some work itself generating things?

An encoder is anything that serializes some data. Think `JSON.stringify()`.

Re: YAML: Probably not so great after all

#292

Post by jtdev »

JoBrad wrote: post #288
zzo38computer wrote: post #270

Earlier quoted context omitted.

I don't aversion to braces. Rather, my issues with JSON is that it doesn't have comments and that you cannot use a optional trailing comma.

And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.

It’s also a lot less obvious. What’s so difficult about wrapping a string in double quotes?

Re: YAML: Probably not so great after all

#293

Post by jtdev »

nine_k wrote: post #274
norcalli wrote: post #267

Earlier quoted context omitted.

I've never understood this. JSON is really not that difficult to work with manually. I tend to write my config files as JSON for utilities I write. What is it with peoples' innate aversion to braces?

JSON is serviceable as an intermediate format, machine-generated and machine-consumed. It is outright bad as a human-operated format. It explicitly lacks comments, it does not allow trailing commas, it lacks namespaces, to name a few pain points. YAML is much more human-friendly, with all its problems.

I often hear the “comments aren’t supported” argument against JSON, but as a daily consumer, creator, and maintainer of JSON, I honestly can’t recall ever _really_ needing comments in JSON. It tends to be somewhat self documenting in my experience.

Re: YAML: Probably not so great after all

#294

Post by jtdev »

bastardoperator wrote: post #202
fabian2k wrote: post #14

I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.

YAML is easier to read and write. That's the benefit. It's also always going to be smaller than anything JSON or XML. Maybe it's not as correct, maybe some people don't like it, I don't really mind it. I don't see it really going anywhere soon either considering Kubernetes and the lack of alternatives in widespread usage. I've never had someone that needed extensive help understanding YAML and that's besides reviewin…

>”YAML is easier to read and write.”

You may be surprised to find that there’s significant disagreement on that point.

Re: YAML: Probably not so great after all

#295

Post by h1d »

jtdev wrote: post #292
JoBrad wrote: post #288

Earlier quoted context omitted.

And the required double quotes around strings. YAML’s string handling is a lot easier to deal with.

It’s also a lot less obvious. What’s so difficult about wrapping a string in double quotes?

It gets annoying when you have to do what seems unnecessary.

Re: YAML: Probably not so great after all

#296

Post by jtdev »

geerlingguy wrote: post #94
rusk wrote: post #77

Earlier quoted context omitted.

I think it's horses for courses. JSON I guess is the best for interchange i.e machine to machine, but I never want to edit it by hand; XML is relatively easy to read but can be quite painful to edit raw, but it can be quite easy to develop a structures editor. I’d favour it for document persistence. YAML is fine for configuration files but I would be careful about how I apply it and would always provide it as a heavi…

ini if needs are crazy simple, YAML if you need a structure like JSON's but with something any human ever needs to interact with. JSON if humans aren't in the loop. TOML, in my opinion, is like a weird mishmash of JSON, ini, and bashisms. Though I have worked with it a lot less than the other formats, so YMMV.

Since when is JSON not human readable/maintainable??

Re: YAML: Probably not so great after all

#297

Post by h1d »

jtdev wrote: post #293
nine_k wrote: post #274

Earlier quoted context omitted.

JSON is serviceable as an intermediate format, machine-generated and machine-consumed. It is outright bad as a human-operated format. It explicitly lacks comments, it does not allow trailing commas, it lacks namespaces, to name a few pain points. YAML is much more human-friendly, with all its problems.

I often hear the “comments aren’t supported” argument against JSON, but as a daily consumer, creator, and maintainer of JSON, I honestly can’t recall ever _really_ needing comments in JSON. It tends to be somewhat self documenting in my experience.

A config file without comments can mean serious annoyance.

If JSON was developed more recently on places like GitHub, it would never have ended up like that with that many deficiencies.

Re: YAML: Probably not so great after all

#298

Post by nine_k »

jtdev wrote: post #293
nine_k wrote: post #274

Earlier quoted context omitted.

JSON is serviceable as an intermediate format, machine-generated and machine-consumed. It is outright bad as a human-operated format. It explicitly lacks comments, it does not allow trailing commas, it lacks namespaces, to name a few pain points. YAML is much more human-friendly, with all its problems.

I often hear the “comments aren’t supported” argument against JSON, but as a daily consumer, creator, and maintainer of JSON, I honestly can’t recall ever _really_ needing comments in JSON. It tends to be somewhat self documenting in my experience.

When maintaining a JSON file, did you ever happen to wonder why a particular value is what it is?

This is where comments belong.

Re: YAML: Probably not so great after all

#299

Post by flukus »

twic wrote: post #180
vinay_ys wrote: post #82

I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security. Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag). If you want, you can also provide a frie…

For the love of god, if anyone reads this, please don't do this! Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc. API-driven configuration has none of these properties. Some Java application servers take this approach of API-driven configuration. It's an improvement over UI-driven configuration, which is what they had before. But it's still si…

> Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc.

Code based configuration offers most of those benefits, just look at some of the suckless tools, if you've never used dwm or written a line of C I bet you can still guess how to configure some stuff here: https://git.suckless.org/dwm/file/config.def.h.html .

It doesn't work for all software of course, but for anything developer centric and/or anything with complex configuration done by experts it's a good choice, particularly for any software going down the path of creating a custom language (tmux, vim, etc). You get the power and flexibility of a full programming language, you get compile time config checks, you get excellent performance, you don't have to learn yet another config language and it's easy to write patches.

It's not great if you're targeting Joe Average, but neither is any configuration format, or any configuration at all.

Re: YAML: Probably not so great after all

#300

Post by h1d »

fabian2k wrote: post #14

I've used YAML as the format for a config file, and I certainly regret that choice. Trying to explain to someone that doesn't know YAML how to edit it without setting them up for failure is quite annoying. There are too many non-obvious ways to screw up, like forgetting the space after the colon or of course bad indentation.

YAML is so bad for human writing. Everytime I write ansible tasks, I get confused with indentation and how to do arrays etc. JSON and YAML is frankly a generation behind compared to TOML or JSON5.
Post reply on HN