3 ms·

> 95% of the time can be thought of as map<string, JsonObject> But for that case you don't need json. A dockerfile-like text file with lines of the form

> 95% of the time can be thought of as map<string, JsonObject> But for that case you don't need json. A dockerfile-like text file with lines of the form STRING other stuff is trivial to parse in any language and without requiring any library. And it's actually human-editable. Using json for such trivial stuff is like using a linear algebra library to compute b/a (the quotient of two numbers) by calling linalg.solve([[a]],[b]). Of course it will work. Of course it is more general. But it feels silly.

maccard 2y ago
> But for that case you don't need json. A dockerfile-like text file with lines of the form I don't think that would solve any of your listed problems with json. The key thing is that it's represented by: struct JsonObject { Dictionary<string, JsonObject> entries; } and that's the entire data structure. Your dockerfile example handles the absolute most basic of cases, e.g. { "foo": ["bar", "baz"] } would be FOO ["bar", "baz"] But when you nest objects .e.g. { "foo": { "bar": "baz" } } The dockerfile-style example is FOO { BAR baz } or FOO BAR baz # Now we're whitespace sensitive Or maybe we're: Foo # What do we put here? Foo.bar baz > Using json for such trivial stuff is like using a linear algebra library I disagree. I think using xml for that is like using a linear algebra library, as you can have: <Foo>Bar</Foo> <Foo value="Bar"></Foo> <Foo><Bar>Baz</Bar></Foo> <Foo bar="Baz"></Foo> <Foo><Bar value="Baz"></Bar></Foo> and end up with the same thing. But with json, it's just: { "Foo": "Bar"} and { "Foo": { "Bar: "Baz" } } E: Formatting
Timon3 2y ago
How does your approach handle keys with spaces? How does it handle multiline strings, escapes and so on? With your approach, I have to either not use these features, do a lot of manual testing to figure out the corner cases of your implementation, or spend a non-trivial amount of time to implement them because they weren't considered from the start. This hardly seems better than just using JSON.
- enriquto 2y ago
  > How does your approach handle keys with spaces? It doesn't, and that's OK; not a big deal. JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers!
  - Timon3 2y ago
    > It doesn't, and that's OK; not a big deal. It's only not a big deal if your use case doesn't require this feature. You don't always have full control over the keys. Say I take over your legacy project, and I need to add a way to configure settings related to file paths. Whoops, suddenly I'm either limited in the FS layout I can use, or I have to implement support for this feature (and properly test it, and document it, and...) > JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers! You can always encode them as strings, no?
    - aragilar 2y ago
      How do you tell the difference between a string and a number then (also, what precision is the number, is it a float or an int etc.)?
      - Timon3 2y ago
        Depends! If you know the schema, you already have this information. If you don't know the schema, the most common approach is to store the type and value in an object, e.g. { "_t": "float64", "_v": "3.14159" }
thiht 2y ago
Cool, now I need to write a custom parser (no matter how simple it is) for your custom format. With no guarantee that it won’t evolve with breaking changes when you realize you forgot to handle some use cases and end up reinventing JSON. JSON is trivial as it is, don’t try to reinvent the wheel badly.
- enriquto 2y ago
  but it's easier to write this "parser" than to call any json library
DanielHB 2y ago
Problem with less popular formats is that there is no official specs or reliable reference implementations, it tends to break when encoding and decoding with different OS/languages/libraries/etc. YAML, JSON and XML have very well defined specs and the encoders/parsers have been proven to be very reliable across OS/language/libraries. JSON in special tends to be the least problematic because it is simpler than the others and the browsers implementation is kind of the canonical implementation.

maccard 2y ago

> But for that case you don't need json. A dockerfile-like text file with lines of the form I don't think that would solve any of your listed problems with json. The key thing is that it's represented by: struct JsonObject { Dictionary<string, JsonObject> entries; } and that's the entire data structure. Your dockerfile example handles the absolute most basic of cases, e.g. { "foo": ["bar", "baz"] } would be FOO ["bar", "baz"] But when you nest objects .e.g. { "foo": { "bar": "baz" } } The dockerfile-style example is FOO { BAR baz } or FOO BAR baz # Now we're whitespace sensitive Or maybe we're: Foo # What do we put here? Foo.bar baz > Using json for such trivial stuff is like using a linear algebra library I disagree. I think using xml for that is like using a linear algebra library, as you can have: <Foo>Bar</Foo> <Foo value="Bar"></Foo> <Foo><Bar>Baz</Bar></Foo> <Foo bar="Baz"></Foo> <Foo><Bar value="Baz"></Bar></Foo> and end up with the same thing. But with json, it's just: { "Foo": "Bar"} and { "Foo": { "Bar: "Baz" } } E: Formatting

Timon3 2y ago

How does your approach handle keys with spaces? How does it handle multiline strings, escapes and so on? With your approach, I have to either not use these features, do a lot of manual testing to figure out the corner cases of your implementation, or spend a non-trivial amount of time to implement them because they weren't considered from the start. This hardly seems better than just using JSON.

enriquto 2y ago
> How does your approach handle keys with spaces? It doesn't, and that's OK; not a big deal. JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers!
- Timon3 2y ago
  > It doesn't, and that's OK; not a big deal. It's only not a big deal if your use case doesn't require this feature. You don't always have full control over the keys. Say I take over your legacy project, and I need to add a way to configure settings related to file paths. Whoops, suddenly I'm either limited in the FS layout I can use, or I have to implement support for this feature (and properly test it, and document it, and...) > JSON has no support for standard floating-point numbers, and that's a bigger problem for me. I can easily change my keys to make them sane, but I cannot change the numbers! You can always encode them as strings, no?
  - aragilar 2y ago
    How do you tell the difference between a string and a number then (also, what precision is the number, is it a float or an int etc.)?
    - Timon3 2y ago
      Depends! If you know the schema, you already have this information. If you don't know the schema, the most common approach is to store the type and value in an object, e.g. { "_t": "float64", "_v": "3.14159" }

thiht 2y ago

Cool, now I need to write a custom parser (no matter how simple it is) for your custom format. With no guarantee that it won’t evolve with breaking changes when you realize you forgot to handle some use cases and end up reinventing JSON. JSON is trivial as it is, don’t try to reinvent the wheel badly.

enriquto 2y ago
but it's easier to write this "parser" than to call any json library

DanielHB 2y ago

Problem with less popular formats is that there is no official specs or reliable reference implementations, it tends to break when encoding and decoding with different OS/languages/libraries/etc. YAML, JSON and XML have very well defined specs and the encoders/parsers have been proven to be very reliable across OS/language/libraries. JSON in special tends to be the least problematic because it is simpler than the others and the browsers implementation is kind of the canonical implementation.