351–360 of 457 posts
Earlier quoted context omitted.
When maintaining a JSON file, did you ever happen to wonder why a particular value is what it is? This is where comments belong.
If it's that important and complex, have an accompanying README that lists line numbers and comments.
Earlier quoted context omitted.
How about JSONL (JSON Lines)? http://jsonlines.org/ Ps. Thanks for (all the) fish, it's my daily driver shell and keeps me that much more sane c.f. the alternatives.
That's really close to [RFC 7464]( https://tools.ietf.org/html/rfc7464 ), JSON Text Sequences. It uses U+001E RECORD SEPARATOR. The `jq` tool supports those if you pass a flag.
Earlier quoted context omitted.
Other than looking ugly and being a pain to type does xml actually suck?
Is there an agreement on whether it’s or pete yet?
There's two types of formats: 1) those people complain about, and 2) those no one use.
Out of curiosity, is there anyone here who doesn't like TOML for configuration?
Earlier quoted context omitted.
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??
It's easier to write than JSON (no need to quote keys, allows trailing commas), has reusability through functions and objects, and can output JSON which is much easier to parse than YAML.
Downside: you need another build step for the config.
From my experience, while YAML itself is something one can learn to live with, the true horror starts when people start using text template engines to generate YAML. Like it's done in Helm charts, for example, https://github.com/helm/charts/blob/master/stable/grafana/te... Aren't these "indent" filters beautiful?
We had joy, we had fun, we had seasons in the sun, but as I added more and more features and syntax to cover specific requirements and uncommon edge cases, I realized I was on an inevitable death-march towards my cute little program becoming sufficiently complicated to trigger Greenspun's tenth rule.
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
There is no need for Yet Another JSON Templating Language, because JavaScript is the ultimate JSON templating language. Why, it even supports comments and trailing commas!
Just use the real thing to generate JSON, instead of trying to build yet another ad-hoc, informally-specified, bug-ridden, slow implementation of half of JavaScript.
Earlier quoted context omitted.
Giving meaning to whitespace causes so many headaches and yet people still embrace Python, for some reason. I don’t understand it.
Your editor makes a world of difference here. Since you shouldn't be writing brace-language code without indents anyways, the biggest issue remaining is mixing tabs and spaces. Gedit makes this a big pain with it's default config (it doesn't even auto-indent) but Atom and IDLE handle it well.
Braces also allow for easily copying and pasting blocks of code because the braces delimit the semantics of the copied text. Because your code is already indented, with white space indentation you have to check that a) you pasted the first line at the right indentation level b) every subsequent line is also at the right level relative to the first line. No small feat.
So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?
The main issue I had with TOML is how much more syntactically noisy it is. Equivalent files with 2-3 levels of nesting usually become at least 50% longer than equivalent YAML. More here : https://hitchdev.com/strictyaml/why-not/toml/
I have some projects where I'm frequently writing and midifying content that resembles the example here, and I use YAML there and plan to keep using YAML. For most other things, I'm just doing configuration, so I use TOML. No reason you need to stick to one or the other.