> Are there any serious advantages of YAML over TOML?
Probably not but you forget YAML came out in 2001 where TOML came out in 2013. Neither are spring chickens but inertia is a hell of a thing. For example, Symfony supports YAML, XML and PHP definitions -- but not TOML. Symfony v2 simply predates TOML and they never got around to ditch YAML for TOML because it's not worth the bothering.
[section]
option=value it the way you want it.
; And these are comments. That's all.
I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things.
I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them. It's same for INI.
You can have "native types" in .ini as well. The difference is you'll be handling them explicitly yourself, and you should do that in defensive programming anway. A config file is a stream of input to your code, and if you don't guard it yourself, you agree what that entails.
If you look at the failure details then most of them are either minor issues about where things like escape characters are/aren't allowed, or about overriding existing tables (previously the spec was ambiguous on that, and I expect that will clear up over time). Note that overview is not entirely fair because it uses the latest (unreleased) version of toml-test where I added quite a few tests.
These kind of imperfections in implementations are of course true for any language, see e.g. YAML: https://matrix.yaml.info – I have no reason to believe it's worse in TOML vs. YAML, XML, JSON, or anywhere else. If anything, it's probably a bit better because it's fairly simple and has a pretty decent test suite.
The problem isn't with the small configuration files, those are just argv put into a file.
Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.
One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever.
The differences don't change the fact that they will all have the same things in common.
Even without a formal spec, we all know what we are free to change and not free to change, and free to assume and not free to assume. The unwritten spec specifies very little, so what? That means maybe it isn't a good choice for some particular task that wants more structure, but that was not what you said and not what I'm ridiculing.
Or was that all you meant in the first place? That without some more to it to define standardized ways to do things, it's not good for these kinds of jobs? I confess I am focusing on the literal text of the comment as though you were trying to say that the term is not meaningful because it is not defined in a recognized and ratified paper.
My point is indeed that it is not meaningful to speak of the INI culture as something directly comparable to a standardised format.
> One may write a single value containing a CSV, another may use a convention of namespaced keys, whatever. One may base64, one may urlencode, whatever.
> The differences don't change the fact that they will all have the same things in common.
I think this is the first time I've seen this sort of neo-romantic argument, where the representation of information is claimed to be irrelevant because, for some unspecified reason, we all known in our hearts what is being said.
Is this a mystical theory you've built on extensively, or something that came to you from the aether just now?
That's all any communication is, is two or more parties using symbols who's meanings a majority agrees on. It does not require a dictionary.
I refer back to the simple fact that the original commenter felt it reasonable to speak the words, believing that others had the same idea what the words meant as they themselves did, and to the fact that I and others did in fact have that same understanding. That means it is utterly silly to be trying to say that the term has no meaning. Does everyone else have telepathy and only poor you are left out of the club? It's even silly to claim that merely you individually just don't know what the term meant, if you would claim to work in any remotely IT related field.
It basically looks like an attempt to look smart backfiring badly.
The reason the things the term doesn't define don't matter is the same reason as for all other terms or symbols. No term is a complete description of anything. It defines what it defines and does not define anything else.
When you say "XML", you still have not said an infinity of things. XML merely defines more than INI. INI defines a certain structure, and you are free to do whatever you want within that structure, exactly like XML and all other formats & protocols.
If they defined everything, then they wouldn't be general purpose frameworks for packaging data, they would be snapshots of specific particular data. In fact they would not even be snapshots but one specific physical instance taking one specific form as it exist in one place at one time somewhere.
There is no way you don't already know all of this, I absolutely credit you with having this much understanding of how symbols work, which makes your argument disingenuous.
If you didn't and your argument was sincere, then you are embarrassingly illiterate for trying to partake in a conversation in this area. Not a crime to be that ignorant, and if so then I apologize for ridiculing a 6 year old who somehow found their way onto HN, but consider yourself now better informed than you were. That a ratified rfc or iso for INI, or any other term, is not required for a term to be valid communication. All that's required is for speaker and listener to both understand it, and such definitions are merely one of many ways for a term to have meaning and for all involved parties to have that mutual understanding.
Wait, I suppose I have to explain what rfc and iso and ieee all mean in this context. Anyone who did not know what .ini meant surely can not recognize any of those either.
How the software operates is of course dependent on the expressiveness of the configuration format, so it is clearly false in most practical senses to claim that the flat key-value format of INI and BICF will generate the same set of problems as formats that allows for list and nesting.
If we accept the assertion that the complexity of a configuration file for the stated scenario is constant across all configuration formats, we will next be asserting that there's no difference in complexity between solutions in x86 assembly and LISP.
You stated a problem: Configure ~6 servers where they share variables.
I can implement it in plethora of ways. The most sensible one for me is to have a general or globals or defaults area where every server overrides some part of this defaults. The file format has nothing to do with the sectional organization of a configuration file. Because none of the files force you to a distinct section organization.
e.g.: Nesting is just a tool, I don't care about its availability. I don't guarantee that I'll be using if that's available.
I can write equally backwards and esoteric configuration file in any syntax. Their ultimate expressiveness doesn't change at the end of the day.
I don't care. All can do whatever I want and need. Only changes how you parse and map. It's hashmaps, parsing and string matching at the end of the day.
If you know both languages equally well, LISP becomes as complex as x86 assembly and x86 assembly becomes as easy as LISP. Depends on your perspective and priorities.
If you don't know how to use the tool you have at hand, even though it's the simplest possible, you blow your foot off.
Probably not but you forget YAML came out in 2001 where TOML came out in 2013. Neither are spring chickens but inertia is a hell of a thing. For example, Symfony supports YAML, XML and PHP definitions -- but not TOML. Symfony v2 simply predates TOML and they never got around to ditch YAML for TOML because it's not worth the bothering.