> 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.
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...