yaml or json , and why ?

Which format do you prefer

  • Total voters
    13
  • Poll closed .
For what? Lots of formats work better for some things than other. gitlab continuous integration uses yaml formatted files; json probably would not work there. But REST interfaces often use json for requests/responses. So, you need to specify what the formatted data is going to be used for.
 
You have to correctly configure your editor. Because when tabs and spaces are mixed you are in trouble.
What is a descend tab size. 4 spaces ?
In my .zshrc i have "tabs -4"
 
I don't think either of them are particularly easy to read.

I agree with aragats delimiting statements by level of indentation is idiotic, evil, stupid. Tabs and or spaces? Yeah, just convert them.

Easy to read: Personally, once you learn the syntax, anything is easy to read.
From a "quickly pick up and understand" JSON was much easier.

The problem is often not in the format itself, but in the programmatic parsing of that format.
Too many people doing things on web-based platforms have a lot of tools that make it trivial to do things, like JSON handling in Javascript.

Take a well formatted JSON, include some array elements, now go and write come C++ code using boost to parse it or format some data in it. Non trivial tasks.

And any of these formats often requires too much knowledge about the structure.
 
You use JSON because other things use JSON and you can plug it into web stuff without any work.

You use YAML because... you have to?
 
(Assuming you're referring to config or related storage of data…)

Some people seem to prefer a particular ordering for certain items, and that can be enforced with schemas when using XML as a config language.

From a parsing perspective, however, JSON is one of the easiest, and it can be written compactly to save disk space or written with proper indentation and line breaks for human consumption. Tools and multiple draft specs for a JSON Schema format exist as well, though I'm honestly unaware of anybody using it. Of course, JSON itself has its own troubles.

I say "No" to YAML whenever possible, and I have mixed feelings about TOML. Apparently I'm not the only one with a distaste for TOML, and you can find plenty of hatred for YAML with little effort. The only advantage YAML seems to have is the fact that there's no need to match opening and closing delimiters as in JSON and XML, and it doesn't suffer from the DRY issues plaguing TOML.

I've seen some support for Dhall as a configuration language (and/or translator to JSON/YAML/Bash?), but I've not used it. It looks interesting/useful at least, though its feature-set make it much heavier than the other languages by comparison.

In my opinion, there is no single "universal" format that works for everybody, and that's fine as long as the format chosen works as intended. Projects may even change formats when one format becomes too cumbersome, and that's fine too, though ideally there'd be a tool to convert to the new format.
 
For the longest time we used plain text and csv. We briefly tried yaml but quickly became frustrated with indentation issues. We also used xml and continued with text which was always simple and never failed us.

Everything should be as simple as possible.
 
  • Like
Reactions: mer
Reflection. Einstein wrote his theory on General relativity as simple as possible. But he could not make it more simple because then it would not be able to solve the problem posed.
 
Alain De Vos said:
he could not make it more simple because then it would not be able to solve the problem posed
Click to expand...
The simplicity is relative too.
I bet, most people chose to use this or that configuration format because they use the corresponding libraries to parse them. That's the "simplicity" for them. To me the simplest way is a plain text like name = value. I would rather write a shell script to convert an existing XML etc. to simple text than install and link against extra libraries.
 
Alain De Vos said:
But he could not make it more simple because then it would not be able to solve the problem posed.
Click to expand...
And that leads directly to part of my first answer, the "For What?"

drhowarddrfine lays out good reasons for "why neither". Most "ini" type of config files have been plain text, no delimiters other than whitespace for a long time and they just work. Add a little bit of logic and you have sections with variables and values.

memreflect lays out very nicely for XML or JSON. XML if one looks at it, closely resembles HTML, so very easy to understand for a lot of people. Delimiters? A lot easier to find missing braces or brackets using an editor than to detect "oh you used tabs here instead of spaces", especially in something written by someone else. You may have your preferred editor set up perfectly, but does someone else?
 
I tend to use .ini for simple things and sqlite for larger things.

Oddly enough I find XML, JSON, YAML it in that niche where it is too much of a faff to use for simple things and not powerful enough for the bigger stuff.

Also, in C tracking all those pointer lifetimes is almost impossible with DOM hierarchies. Same with C++ unless you are using a decent XML parser (which is rarely the case).

That said, I recently had really good experience with using Lua as a config file. 99% of the time it just stores data in a table. But has the added option of for loops, if statements for those few times you need a tiny bit of logic. It is also really portable (c89) or has loads of pure-language clones requiring no time-consuming bindings.
 
Puppet can use either JSON or YAML for hiera. When I first started with Puppet I couldn't get my head around the indentations, kept introducing errors. So the first installs I used JSON for hiera. Now a couple of years later, much more used to YAML I've switched back. YAML is just easier to write (using good settings in vi/vim helps too), JSON is fine for automated processes and generation but entering it by hand is a royal PITA.
 
You must log in or register to reply here.
Back
Top