I think I’d prefer JSON over both XML and YAML when dealing with config files.

XML is just to verbose, making it harder to parse in my brain.

YAML is whitespace sensitive which I hate in general.

I'm fine with JSON except it doesn't officially do comments, but that's a big deal IMO

Which is especially problematic for config files where you want helpful hints or a place to store the “old value” while you do something else with the app. I have an app where I change a specific config almost every time I use it. I usually just copy the entire darn node and rename it to something that doesn’t get deserialized. Closest I can get to holding the value in a comment.

Might be interesting to check out json5.

https://json5.org/

This is a great example why we should avoid writing custom DSLs and just use a proper programming language.

Then again, Gradle has come to show why that is a terrible idea.

I think at some point 24 out of 28 Gradle projects I had access to at a certain customer had variations in either kotlin/Groovy style or the way they did or didn't use variables, how they did or didn't do loops or maps and what not.

With Maven you (or someone who know Maven) can immediately look at a rather small, very standardized file and start making educated guesses and so can an IDE.

With Gradle you sometimes have to run it to actually know what it will do.

I had the same experience with Maven vs SBT (scala build system, config is scala). At first it is really cool to have access to a full programming language (in particular when it is the same as the one the project is in, which means that you do not need to "switch brains" when working on the config), but quickly people start trying to be smart or cute, and it becomes a big mess. In particular in Scala, where people _love_ defining new DSLs and favor cuteness over readability. After two years working with SBT I still do not really understand some of the DSLish constructs used in there (and I tried to read the docs).

On the other side I fell in the trap of trying to overcome the limitations of purely declarative config formats by using jinja templates, which also ended up being a very bad idea and a maintenance nightmare.

For most projects, my approach is now to try to be as standard as possible compared to the particular community in the tech at end, and resist the urge to be smart or cute (hard!). Configuration always sucks, and I now prefer to just suck it up and get done with the config part, rather than loosing time reinventing the wheel, ending with a config that still sucks _and_ no one understands.

The good thing about Maven is it is XML so everyone wants to keep it as short as possible ;-)

(More seriously: with Maven shorter and more boring is a sign that everything is correctly configured. Maven works by the convention over configuration principle so if you don't configure something it means it follows the standard. Which again means if you see someone has configured for example a folder or something that usually isn't configured it means they have put something in a non standard location.)

I think it's only popular in the scala ecosystem, but I find HOCON to be a pretty nice superset.

You know that JSON is subset of yaml, right?

Since most people’s (especially critics) understanding of YAML is stuck on YAML 1.1 where that wasn't quite true, probably not.

The commenter said they preferred json over yaml because yaml is whitespace sensitive; Json is not

yaml's feature set is also too broad, forcing safe loaders

I think the point is that if something accepts YAML, you can feed it JSON without issue.

> yaml's feature set is also too broad, forcing safe loaders

Could you elaborate?

Yaml tags allow for serialization of native types, and has been abused to run malicious code.

I think you can also make circular references in yaml effectively making a zip bomb

This is why you have yaml.safe_load in Python and SafeConstructor in Java's snakeyaml package

The end result is that you should not use yaml to handle untrusted data unless you are also explicitly handling it safely

Any de-serialization should be done via safe loaders. Using `require()` or `eval()` isn't something I'd do outside of a very narrow set of scenarios.

The json modules in the same languages doesn't support the madness and doesn't necessitate a safe loader

It's possible someone could come along and write a json library that would support this, but somehow we have made it this far without it and that's a good thing

The point is that yaml and xml both have side effects in the form of require and eval that json won't, and frequently people are unaware of this

I feel I must still be misunderstanding something. OWASP has pages of resources which talk about the lack of safety of JSON:

https://owasp.org/search/?searchString=json

Perhaps yaml and xml have _more_ ways to inject behavior into an application, but I would still not consider JSON safe in any way. Why would JSON.parse() even exist if `require()` and `eval()` were safe to use?

Much easier to have invalid JSON than invalid XML as jsonschema isn’t even close

XML is whitespace sensitive, unless your particular schema just doesn't care about whitespace text nodes.

In XML's defense, the attribute-vs-child-element choice is always obvious and straightforward when you're using it as a markup language. It's only when you use it as object notation that it becomes wonky, because there the choice simply doesn't map to any straightforward characteristic of the problem domain. I'm not sure I want to hold XML responsible for not being good at being something it isn't.

And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.

I'm not criticizing having attributes-vs-child-elements. The problem with XML is not that it exists or that it is a particularly badly designed markup language.

The problem is that XML is ill-suited for configuration files.

Yeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.

You think that JSX would be suited for configuration files?

Why?

I don't understand your comment.

Because people reinvent half of it, different half every time in each project, and call it 'configuration' which somehow gives them licencia poetica for whatever crazy dung they come up with.

Compare ansible vs helm vs github actions vs literally anything with nontrivial config.

Note that if you asked me for real, I'd be a dhall proponent, but most normal people look at me funny the first time they hear it and then the second time they see the syntax.

dhall looks nice actually! Thanks for elaborating :)

Why? I can store it in version control. I can validate if the file has syntax errors or schema errors etc. etc. With a proper platform it's easy to generate or parse. It allows for both hierarchical structures (looking at you .ini). The only downside might be that you need a larger library to parse it. But i probably encounter xml somewhere along the line anyway due to interactions with a 3rd party system, so that point is moot.

You have a low bar for config languages. I'd also like one to not be overly verbose, not be clearly intended for markup instead of object storage and not have security issues until you configure the parser just right (though that's often not an issue with configs). XML fails all of these, and YAML isn't much better.

If we're limiting ourselves to just JSON, INI, XML and YAML as potential choices, I get why people cling onto one of these suboptimal choices and then fiercely defend it, but there are other options. There's libconfig, JSON5, Dhall, various interpreted languages...

Sadly these alternatives are far from mainstream and have no support in standard libraries, so I think most developers will continue to pick whichever common option's issues they can deal with.

I'd like my config files to have two words in it "do it" and for it to just know what I want.

But at the end of the day that's not possible because reality intrudes. You give up a lot for that lack of verbosity, not everyone will agree that it's a worthy tradeoff.

It's a noble goal to want a simple configuration format, toml is far from the simplest, line separated options format is simpler. The fact that it needs a parser indicates that it creates a bigger parsing problem than necessary.

> And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.

“YAML ain't markup language” is kinda the whole point.

For a full year it stood for "Yet Another Markup Language".

First draft: https://yaml.org/spec/history/2001-03-30.html

Last draft calling it that: https://yaml.org/spec/history/2001-12-10.html

First draft with the new acronym: https://yaml.org/spec/history/2002-04-07.html

It's also funny that the file extension YML is the successor of XML, so the rest is probably a backronym from that.

Wouldn't the successor of XML be XMM?

Next you'll be telling me Beyonce's sisters should be named Beyoncd and Beyoncf instead of Aeyonce and Ceyonce.

Feyonce can’t get anyone to believe she’s married and Vakira’s has astonishingly honest hips

Judging from BCPL, the successor should just be Y.

The file extensions for yaml is .yaml, .yml is the alternative because of legacy 8.3 systems.

The thing is if you're using it as configuration language, object notation is correct, not markup.

I'm curious why you think that is? Especially since you are likely to want to style the configuration for display to the user in many cases, having it be a document makes a lot of sense.

That is, if the value is something you would expect to be able to show to a user, then it probably shouldn't be at attribute. If it is a value that changes how you would show it, then attribute makes a lot more sense.

I also think a strong adherence to any preference between attribute and markup is a touch too dogmatic. The only real distinction at the language level is if you allow children, or not. If it can have children, it pretty much has to be a child and not an attribute.

Ok forget the difference between attribute and markup. What is the "right" way to think of this:

    <foo>
      <bar>1</bar>
      <bar>2</bar>
      <baz>3</baz>
      <baz>4</baz>
    </foo>

Why do you think there is a "right" way?

I recently started a new project, and just outright didnt want to use yaml to do it. Sadly, im not everyone, and if i plan to release this project, i need to account for that. Whats a guy to do?

Ill tell ya hwhat... I made some simple functions; one to load any yaml/toml/json from file, by just looking at the extension (and providing an override for not normal file extensions). Another to output any data as yaml/toml/json.

I defaulted to using toml for my project, but have provided ways for everyone to be happy, with zero mucking around.

Aaaaaand for the not so subtle promotion, https://pypi.org/project/atckit

Located in the UtilFuncs class.

What is the point of substituting yaml for something even worse?

Worse is subjective.

In any case, the library i linked has the functionality to load any of the three configuration types, so while i prefer toml, if you grabbed my (under development) project, and hate toml, you can use yaml or json, if you wish.

I built it to make it so that average users can make their own config. The main system works off on only XML files.

>But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it.

not all configurations are maintained by developers, or at least theoretically they shouldn't be.

> But now I realize that modern developers don't want a GUI to manage their config.

I think, like almost all software, it depends on personality and other factors like how frequently someone has worked with a language/tool/etc.

If someone has the traditional Unix "read all the man pages in their entirety" kind of brain, they'll probably never use a GUI.

If someone has more of a "learn by example, then refer to the docs to cover cases the examples didn't handle" brain, a GUI can be a much easier way to clearly expose all the potential functionality of a tool. It's much easier to understand (IMO) than e.g. a template configuration file with every possible option present but commented out.

> a well-defined subset of XML

No. You need to define what configuration files are valid or not, but a subset of XML on the basis of syntactic and structural alternatives is lame and nonstandard.

Get a library that parses actual XML, allow anything reasonable as input (for example, no external entities, DTDs, PSVI etc. to keep the file self contained) and "flatten" CDATA sections, entities, namespace prefixes, idrefs etc.