151–160 of 163 posts
Earlier quoted context omitted.
Otoh, I got plenty of support requests from people not understanding that the space at the end of a line in an .ini file is part of the value. (app is using glib ini parser) Quoting at least makes it clear what's part of the value.
What sort of nightmare format from hell has significant whitespace at end of line?
`[[foo]]` syntax is not obvious at all. It's a bit weird that top-level declarations use ini-like syntax, but values can use JSON-like syntax, and there are multiple syntaxes to express the same data structure.
It doesn't strike me as very elegant, or obvious. Still, it is less annoyingly-inflexible than JSON, less verbose than XML, and less footgunny than YAML.
Earlier quoted context omitted.
1 - If you google 'config stdin' you'll see a number of good reasons a program might want to accept configuration on stdin. (also, not that it matters, but my program read it from a file) 2 - Those IP addresses are probably not the main data the program processes. In my case, they were configuration, describing where an auditing processor scrapes input and how to allocate compute.
Scraping is not bootstrapping. That's the main process. Main input can have several sources.
Earlier quoted context omitted.
I've been using TOML recently and what displeases me most is that almost all string values need to be quoted.
Otoh, I got plenty of support requests from people not understanding that the space at the end of a line in an .ini file is part of the value. (app is using glib ini parser) Quoting at least makes it clear what's part of the value.
Earlier quoted context omitted.
JSON is great, but not for config: It was never really meant to be written by humans.
Really? How so? I thought the whole reason it won over XML for HTTP stuff was precisely because it could be easily written and read by humans.
Notice I did not mention readability. JSON was always meant to be human-readable; and its popularity is a testament to the rapid turnaround on debugging that the readable aspect of JSON affords. This is, say, in contrast to BSON which is similar but not humanly readable, and unsurprisingly less popular despite its bandwidth advantages.
Config formats are, by raw bulk, generated by humans, and need to be readable (ideally reproducibly across implementations) by computers.
Earlier quoted context omitted.
JSON is great, but not for config: It was never really meant to be written by humans.
I agree totally with you, but designing a language that's not "meant for humans" is an _incredibly_ stupid idea. Of course humans will try and write any protocol by hand. Who's gonna stop me? If it looks like text, make it as easy as possible for humans to consume and write by hand. Period. That's a small but very important reason why HTTP rules the world.
Earlier quoted context omitted.
> GUIDs, IP Addresses, and byte arrays. In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000 As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but…
It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…
I feel like that's something that's more an appropriate concern for the application, and not something that ought to be baked into the configuration format itself. For example:
> E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String".
Can you not just pass the System.String you get from the decoder into System.Guid's constructor and handle the resulting error should that string not actually be a GUID?
Like, my problem with a lot of config file formats is that they're frequently too clever about assuming types of things when I would much rather they be strings by default for me to interpret later.
> If you roll your own ["hex-string-to-byte-array" decoding function], it'll be about 10x less efficient than something done properly using SIMD instructions.
Unless you roll your own that uses those SIMD instructions, whether in hand-written assembly or in a programming language with a compiler smart enough to use SIMD for this.
This does, however, reek of a premature optimization.
Earlier quoted context omitted.
It sounds like you should store your configuration in some sort of KVS (Consul or etcd) or database (SQL) with a frontend rather than flat text files. There exists tooling for all of that. If you're really going for Excel, why not even make a plugin that hooks in to it. Personally I'd find that horrible, but if it works for you and your team has no objections, why not. I'd wager that the major reason no one has taken…
There is an awful lot of middle ground between the scale where it's faster to just click through a GUI, and the scale where a database engine makes sense. Sure, if I were provisioning 10K+ more-or-less-but-not-entirely-the same objects, I'd be reaching for a SQL database engine of some sort. For about 10 things I'd just grit my teeth and click through a GUI manually. In between 10 items and 10K is where things get in…
Whoa cool. I remember seeing Tom’s initial proposal/spec for TOML on here years ago. Like maybe a decade even. Glad to see it’s still out there and actually been implemented
Earlier quoted context omitted.
my understanding is that the batteries included philosophy wasn't really successful. probably it would have been better if they had a smaller standard library providing core language-level functionality and then many blessed p packages that with independent versioning
It was successful at the time. Remember Python is nearly 30 years old now, and has always had the worst dependency management of any major language.