4 ms·

Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternati

by s3m4j 8y ago

Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.

reaperducer 8y ago
He doesn't have to propose an alternative to have an opinion on it. If I don't enjoy a movie, I'm under no obligation to suggest another. It's an opinion. It can stand alone.
- 0xffff2 8y ago
  In your analogy, the alternative is to not see the movie. The analogous alternative would be to... what? Not use config files? Doesn't seem like much of an alternative to me.
gilrain 8y ago
It seemed to me that he favors TOML, but I agree it'd be interesting to read an article advocating for his preferred format.
- Carpetsmoker 8y ago
  I wrote this article, and at this point I don't really have a strong preference for any one format. I think a lot depends on what it's used for. YAML can actually be pretty useful. For example, recently I wrote a tool to generate OpenAPI/Swagger files from Go source code, and outputting that as YAML works pretty well, as YAML is quite easy to read for that. YAML can also be a good choice to serialize some things to disk, like program state. JSON can also be a good choice for that, as can TOML. But for other things ... it's not so great. I should probably write an article detailing this at some point, but ... $ ls -1 /data/code/arp242.net/_drafts | wc -l 64 So much stuff I need to finish :-( I've added your suggestion there though!
ezrast 8y ago
This is almost always the case with YAML criticism, which is a perennial topic in programming communities. Coming up with "a better YAML" is easy; getting anyone to use it is hard - even harder than getting people to use a new programming language because configuration files have to be touched by end users, and they all know YAML already. Furthermore, all of the "better YAMLs" that exist solve a different subset of issues based on the whims of the author. I like indentation-based syntax for config files (though not for programming languages, go figure), so half the alternatives look worse rather than better to me, and reasonable people can also disagree on things like when strings should require quotes and what should be a valid hash key and so on. There are so many bikes to shed that I don't see us ever settling on an alternative without major buy-in from one of the big players in tech. Until then, I'm happy to let YAML win. It's just not broken enough for me to get worked up about.

by s3m4j 8y ago

Not agreeing or disagreeing, but I read both this and his other post about JSON as configuration file and I have not seen him propose and argue for an alternative.

reaperducer 8y ago

He doesn't have to propose an alternative to have an opinion on it. If I don't enjoy a movie, I'm under no obligation to suggest another. It's an opinion. It can stand alone.

0xffff2 8y ago
In your analogy, the alternative is to not see the movie. The analogous alternative would be to... what? Not use config files? Doesn't seem like much of an alternative to me.

gilrain 8y ago

It seemed to me that he favors TOML, but I agree it'd be interesting to read an article advocating for his preferred format.

Carpetsmoker 8y ago
I wrote this article, and at this point I don't really have a strong preference for any one format. I think a lot depends on what it's used for. YAML can actually be pretty useful. For example, recently I wrote a tool to generate OpenAPI/Swagger files from Go source code, and outputting that as YAML works pretty well, as YAML is quite easy to read for that. YAML can also be a good choice to serialize some things to disk, like program state. JSON can also be a good choice for that, as can TOML. But for other things ... it's not so great. I should probably write an article detailing this at some point, but ... $ ls -1 /data/code/arp242.net/_drafts | wc -l 64 So much stuff I need to finish :-( I've added your suggestion there though!

ezrast 8y ago

This is almost always the case with YAML criticism, which is a perennial topic in programming communities. Coming up with "a better YAML" is easy; getting anyone to use it is hard - even harder than getting people to use a new programming language because configuration files have to be touched by end users, and they all know YAML already. Furthermore, all of the "better YAMLs" that exist solve a different subset of issues based on the whims of the author. I like indentation-based syntax for config files (though not for programming languages, go figure), so half the alternatives look worse rather than better to me, and reasonable people can also disagree on things like when strings should require quotes and what should be a valid hash key and so on. There are so many bikes to shed that I don't see us ever settling on an alternative without major buy-in from one of the big players in tech. Until then, I'm happy to let YAML win. It's just not broken enough for me to get worked up about.