> I'm a fan of either using a full-blown programming language or ini files
How do you persist complex multi-object state? Think nested lists of objects with references to one another.
If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().
you cut off the part of my statement that answers your question
> if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json.
My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to everything else.
Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.
> you don't have a configuration format but a serialization format
While I better appreciate what you are saying now (you don't have a solution), the only appreciable difference between "config" and "serialization" is that of write frequency - config is seldom updated, serialization is often updated.
Otherwise, they are the same problem with the same solution - you might provision resources differently based upon "dynamic" vs "static" data, but that's an operational perspective. From the perspective of the application maintainer, there is no difference.
I'm going to submit that if you think configuration and serialization are the same problem it's time to step back and re-evaluate what you're doing, which is really the authors point.
As Joel Spoelsky said years ago, if you abstract far enough up everything starts to look the same but that doesn't make it so
At the end of the day you could claim that all data exchange is exactly the same, and indeed Claude Shannon showed all information is just data, but that misses the point entirely. All humans are exactly the same and yet sex between them can look vastly different based upon such details as genitals.
> if you think configuration and serialization are the same problem
Except that's precisely not the point...rather the formats they are written in are the same, they are indistinguishable.
Reductio-ad-absurdum, if all data exchange is the same then there is no benefit to any format, just write binary strings with null-terminal characters. Except for the many downsides to that approach, so it turns out that they are not the same...
And never-the-less, if all configuration were not serialization, there would be not be any need to be generating config via a different language per the OPs' post...
So we find the similarities between configuration and serialization to be more pertinent than their dissimilarities wrt to format.
INI is absurd for any complex configuration, "just use a turing complete language" is as good an answer as deciding to write binary data randomly...
oh look, the internet denizen was able to weave their way through a rationalization, that's certainly never been done before!
What makes it even more absurd is that we do, in fact, have binary serialization protocols and they're very popular especially amongst companies dealing with scale.
> Values in Cap'n Proto messages are represented in binary, as opposed to text encoding used by "human-readable" formats such as JSON or XML. Cap'n Proto tries to make the storage/network protocol appropriate as an in-memory format, so that no translation step is needed when reading data into memory or writing data out of memory.
---
But that's actually the fucking point, serialization only looks the same as configuration if you've gone too high up the abstraction ladder and lost your perspective and that _is_ the point of TFA. At some point you need to stop and ask if what you're doing is really the right approach.
You've destroyed your _own_ point with your long-winded, weaving, rationalization.
and to top it all off, you've strawmanned a point I've clarified already. It makes you look like an asshole. I've never claimed ini works well for complex configuration, I said the opposite in fact.
> oh look, the internet denizen was able to weave their way through a rationalization, that's certainly never been done before!
Yes, I gathered a couple replies ago you weren't interested in meaningful discussion...and probably hadn't even read anything I'd said.
> You've destroyed your _own_ point
What point? I asked you a question. You continually divert and misdirect.
Now the only point of contention I have left with you: Configuration and Serialization are the same thing, at the format layer. You mumble some nonsense about an abstraction ladder, but the truth is you're climbing it. The difference between only appears at higher levels of abstraction.
> I've never claimed ini works well for complex configuration
And yet you never made a claim about what works well. This is precisely the reason JSON/YAML are popular, and most people ditched INI, people don't care about your higher order abstraction, they just want a format that gets the job done, and doesn't get in your way.
How do you persist complex multi-object state? Think nested lists of objects with references to one another.
If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().