4 ms·

Surely you shouldn’t be limited to types as interpreted and represented in the low-level config parser library but should have a strongly typed representation i

by 3np 6y ago

Surely you shouldn’t be limited to types as interpreted and represented in the low-level config parser library but should have a strongly typed representation i of the config structure that you implement in whatever language you’re using. C# is a good example. JSON doesn’t have any of these types. It doesn’t even make a distinction between integers and other numbers. Yet it’s common practice to marshal these into the kind of types you mentioned at ingestion. At the end of the day, if you type it with your keyboard, it’s essentially a string. I think it’s completely fine that all this functionality is part of neither programming languages core libraries nor configuration file formats - there is no one-size-fits-all here. There are plenty of configuration frameworks that do what you ask for.

jiggawatts 6y ago
> whatever language you’re using. This is the #1 mistake people make when designing, evaluating, or critiquing frameworks, file formats, protocols, and the like. I don't get to choose the language. I'm not writing 100% of the code that I use. In fact, I have control over approximately 0.00001% of the code involved in processing a typical JSON file, or TOML file, or YAML file. OTHER people control the language choice, and it certainly won't be ONE language. It'll be many languages. If submit an ARM template to Azure, it'll go through at least three languages in the process: C#, Python, and JavaScript. Possibly C++ and F#. Who knows? Even when the language is reasonably consistent, such as JavaScript, there is very little consistency in the specific parser used. After the parser-level inconsistencies, there's further inconsistencies in how the stringly-typed data is converted into some more strongly typed format. That's just up to whoever wrote the code that consumes the data. There is exactly zero standardisation of this. None whatsoever. It's almost never documented, and there's just no way to know without experimenting. NONE of this is in my control, or your control. I can't emphasise this enough. Stop thinking in terms of a developer sitting down in front of an IDE with a new project, where they type all of the code in, hit compile and ship the binary to some customer. Start thinking in terms of having to deal with inconsistencies between Terraform, Cloudformation, Amazon, AWS, GCP, and CloudFront. Starting thinking about having to publish something like a Rust module to three different crate repositories, and cache it locally, and have it work properly with the various IDEs people use. Start thinking in terms of security vulnerabilities of different parsers at different layers escaping data differently, or smuggling data using encodings accepted by the back-end past web application firewalls that don't understand that particular encoding. This stuff matters. JSON famously had a definition so short that it fit on a business card. Less is more, right? This "simplicity" lead to fun blog posts titled "Parsing JSON is a minefield": http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php The designer of TOML seems to have never read that article, or if he has, he hasn't learned any lessons from it...
pjc50 6y ago
> At the end of the day, if you type it with your keyboard, it’s essentially a string. I mean .. yes, but that's the exact chaos we're trying to mitigate? The different types may all get serialised as strings, but their semantics are different. And the purpose of strong typing is to make it harder for people to put semantically wrong things in the wrong place. (This is semantic markup vs <font size=2> all over again, isn't it)
- GoblinSlayer 6y ago
  Deserializer provides that desired semantics. You can't express all types in markup language, because its type system is inherently limited.

by 3np 6y ago

jiggawatts 6y ago

> whatever language you’re using. This is the #1 mistake people make when designing, evaluating, or critiquing frameworks, file formats, protocols, and the like. I don't get to choose the language. I'm not writing 100% of the code that I use. In fact, I have control over approximately 0.00001% of the code involved in processing a typical JSON file, or TOML file, or YAML file. OTHER people control the language choice, and it certainly won't be ONE language. It'll be many languages. If submit an ARM template to Azure, it'll go through at least three languages in the process: C#, Python, and JavaScript. Possibly C++ and F#. Who knows? Even when the language is reasonably consistent, such as JavaScript, there is very little consistency in the specific parser used. After the parser-level inconsistencies, there's further inconsistencies in how the stringly-typed data is converted into some more strongly typed format. That's just up to whoever wrote the code that consumes the data. There is exactly zero standardisation of this. None whatsoever. It's almost never documented, and there's just no way to know without experimenting. NONE of this is in my control, or your control. I can't emphasise this enough. Stop thinking in terms of a developer sitting down in front of an IDE with a new project, where they type all of the code in, hit compile and ship the binary to some customer. Start thinking in terms of having to deal with inconsistencies between Terraform, Cloudformation, Amazon, AWS, GCP, and CloudFront. Starting thinking about having to publish something like a Rust module to three different crate repositories, and cache it locally, and have it work properly with the various IDEs people use. Start thinking in terms of security vulnerabilities of different parsers at different layers escaping data differently, or smuggling data using encodings accepted by the back-end past web application firewalls that don't understand that particular encoding. This stuff matters. JSON famously had a definition so short that it fit on a business card. Less is more, right? This "simplicity" lead to fun blog posts titled "Parsing JSON is a minefield": http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php The designer of TOML seems to have never read that article, or if he has, he hasn't learned any lessons from it...

pjc50 6y ago

> At the end of the day, if you type it with your keyboard, it’s essentially a string. I mean .. yes, but that's the exact chaos we're trying to mitigate? The different types may all get serialised as strings, but their semantics are different. And the purpose of strong typing is to make it harder for people to put semantically wrong things in the wrong place. (This is semantic markup vs <font size=2> all over again, isn't it)

GoblinSlayer 6y ago
Deserializer provides that desired semantics. You can't express all types in markup language, because its type system is inherently limited.