26 ms·

I agree that it's a tragedy, XML had so much standardization, tooling, validation, etc available, it was great. But people used it for configuration and manuall

I agree that it's a tragedy, XML had so much standardization, tooling, validation, etc available, it was great. But people used it for configuration and manually writing it, which sucked. 15 years later and JSON still is still very far from the standardization and tooling that XML had at the time. It reminds me of the NoSQL thing from back then too, oversimplified it was "what if we chuck JSON blobs in a key/value store?". It took years to realize that relational databases and SQL weren't actually that bad, and / or that NoSQL had a long term cost.

whizzter 1y ago
And that was the downfall.. 1: Standardization was made by committee lovers and/or architecture astronauts leaving us with overly convoluted (sometimes to fit lacklustre object models in early OO languages) and complex ways of working. 2: Complexity that introduced security vulnerabilities Sure, there was some great tooling available, but how much of it was needed because all complexity made it hopeless to work with without the tooling? I used it for configuration and serialization in some projects, and it was actually great but I almost always diverged from the bloated norms and defaults for readability/writeability (that made it a bit annoying to specify serialization rules). I mean, why did people prefer? <object><property name="somename"><int32>123</int32></property></object> Over just? <object somename="123"/> Yeah there is so much "flexibility" in those above designs but it wasn't needed 99% of the time. JSON was and is so far the best popular compromise between "just plain data" and "some" structure to make automated processing non-painful. Also as an improvement over XML collections (do you created a container element to specify container target leading to bloat or just map some of the sub-elements to specific collections and hope you don't run into ambiguities?) is that collections are just specific lists to a property. The biggest drawback of JSON is that we never had a way to handle type specializations/subtyping but had we done that we might have not gotten the universal acceptance across languages. Yes, comments but whenever you need that you can make a single-line regexp to strip a useful subset of them without affecting anything by the standard by removing matches of /^\s*\/\/[^\r\n]*/mg
BobbyTables2 1y ago
Fortunately we learned our lesson with YAML. (/s) Easier to write than JSON. But weirdly harder to get right in other ways, especially for nesting things. Almost made the mistake of becoming simple to parse. Alas, defeat was again snatched from the jaws of victory on that one…
- sandreas 1y ago
  Technically YAML is a superset (or subset?) of JSON. https://yaml.org/spec/1.2-old/spec.html#id2759572 https://yaml.org/spec/1.2-old/spec.html#id2759572 However, I find the toml language somehow the better tech, while I still think that configuration should not be a "format" but a language. I think at least the recomposition of values with other values should be possible: CONFIG_PATH="$MAIN_PATH/config" And why would you configure: DEV_PATH="dev" PRD_PATH="prod" when you could do MAIN_PATH=env.IS_PROD ? "prod" : "dev"
  - yencabulator 1y ago
    TOML with any kind of nested structure is an utter pain. It's only usable for the most trivial content.

whizzter 1y ago

And that was the downfall.. 1: Standardization was made by committee lovers and/or architecture astronauts leaving us with overly convoluted (sometimes to fit lacklustre object models in early OO languages) and complex ways of working. 2: Complexity that introduced security vulnerabilities Sure, there was some great tooling available, but how much of it was needed because all complexity made it hopeless to work with without the tooling? I used it for configuration and serialization in some projects, and it was actually great but I almost always diverged from the bloated norms and defaults for readability/writeability (that made it a bit annoying to specify serialization rules). I mean, why did people prefer? <object><property name="somename"><int32>123</int32></property></object> Over just? <object somename="123"/> Yeah there is so much "flexibility" in those above designs but it wasn't needed 99% of the time. JSON was and is so far the best popular compromise between "just plain data" and "some" structure to make automated processing non-painful. Also as an improvement over XML collections (do you created a container element to specify container target leading to bloat or just map some of the sub-elements to specific collections and hope you don't run into ambiguities?) is that collections are just specific lists to a property. The biggest drawback of JSON is that we never had a way to handle type specializations/subtyping but had we done that we might have not gotten the universal acceptance across languages. Yes, comments but whenever you need that you can make a single-line regexp to strip a useful subset of them without affecting anything by the standard by removing matches of /^\s*\/\/[^\r\n]*/mg

BobbyTables2 1y ago

Fortunately we learned our lesson with YAML. (/s) Easier to write than JSON. But weirdly harder to get right in other ways, especially for nesting things. Almost made the mistake of becoming simple to parse. Alas, defeat was again snatched from the jaws of victory on that one…

sandreas 1y ago
Technically YAML is a superset (or subset?) of JSON. https://yaml.org/spec/1.2-old/spec.html#id2759572 https://yaml.org/spec/1.2-old/spec.html#id2759572 However, I find the toml language somehow the better tech, while I still think that configuration should not be a "format" but a language. I think at least the recomposition of values with other values should be possible: CONFIG_PATH="$MAIN_PATH/config" And why would you configure: DEV_PATH="dev" PRD_PATH="prod" when you could do MAIN_PATH=env.IS_PROD ? "prod" : "dev"
- yencabulator 1y ago
  TOML with any kind of nested structure is an utter pain. It's only usable for the most trivial content.