4 ms·

May I suggest using TOML, which in my experience has been the perfect blend of human readability while having good tooling. https://toml.io/en/ https://toml.io

May I suggest using TOML, which in my experience has been the perfect blend of human readability while having good tooling. https://toml.io/en/ https://toml.io/en/

viraptor 2y ago
Their dictionaries and arrays split into ini-like sections are not very readable though. The double [[ is just nasty and not possible to apply in all situations (array in map in array).
- zahlman 2y ago
  > not possible to apply in all situations (array in map in array). Yes, that's largely why inline tables and arrays exist: >>> tomllib.loads(""" ... [[outer]] ... first = [1, 2, 3] ... second = [4, 5, 6] ... ... [[outer]] ... third = [7, 8, 9] ... fourth = [10, 11, 12] ... """) {'outer': [{'first': [1, 2, 3], 'second': [4, 5, 6]}, {'third': [7, 8, 9], 'fourth': [10, 11, 12]}]}
  - lifthrasiir 2y ago
    TOML explicitly disallows newlines in inline tables, so that's not a full solution (if you agree that there are some situations where multi-line inline tables are indeed required).
hombre_fatal 2y ago
Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting. Once you want to have arrays of nested objects or objects with arrays, I immediately wish I was just reading JSON so I knew where I was in the tree. And for that reason, I don't think it's a full contender. I want an answer for the hard cases like nested data, not just another way to write the simple cases which is what TOML is. For example, [[a.b]] x = 1 [a] y = 2 Versus: { "a": { "b": [ { "x": 1 } ], "y": 2 } } It's easy to complain that the latter is noisier. But that's nothing compared to being clear.
- okanat 2y ago
  This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.
  - Alex-Programs 2y ago
    I think it works quite nicely in Cargo as you don't generally need much nesting, but anything with depth should use JSON. It's the perfect format for clearly displaying hierarchy.
    - okanat 2y ago
      It works only for trivial projects that are compiled in a roughly up-to-date and popular environment. Custom distros, vendored forks, closed-source software, firmware projects etc. all end up with hairy Cargo files. A systems language should recognize handling complexity gradually is a part of one of its use cases.
- zahlman 2y ago
  It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be: a = { b = [ { x = 1 } ], y = 2 } (And yes, that can be the entire document; you can have an inline table before the first table header.) Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway. But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time). I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.

May I suggest using TOML, which in my experience has been the perfect blend of human readability while having good tooling. https://toml.io/en/ https://toml.io/en/

viraptor 2y ago

Their dictionaries and arrays split into ini-like sections are not very readable though. The double [[ is just nasty and not possible to apply in all situations (array in map in array).

zahlman 2y ago
> not possible to apply in all situations (array in map in array). Yes, that's largely why inline tables and arrays exist: >>> tomllib.loads(""" ... [[outer]] ... first = [1, 2, 3] ... second = [4, 5, 6] ... ... [[outer]] ... third = [7, 8, 9] ... fourth = [10, 11, 12] ... """) {'outer': [{'first': [1, 2, 3], 'second': [4, 5, 6]}, {'third': [7, 8, 9], 'fourth': [10, 11, 12]}]}
- lifthrasiir 2y ago
  TOML explicitly disallows newlines in inline tables, so that's not a full solution (if you agree that there are some situations where multi-line inline tables are indeed required).

hombre_fatal 2y ago

Like YAML, it's only better in the simple case where everything is top-level and there's only one level of nesting. Once you want to have arrays of nested objects or objects with arrays, I immediately wish I was just reading JSON so I knew where I was in the tree. And for that reason, I don't think it's a full contender. I want an answer for the hard cases like nested data, not just another way to write the simple cases which is what TOML is. For example, [[a.b]] x = 1 [a] y = 2 Versus: { "a": { "b": [ { "x": 1 } ], "y": 2 } } It's easy to complain that the latter is noisier. But that's nothing compared to being clear.

okanat 2y ago
This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.
- Alex-Programs 2y ago
  I think it works quite nicely in Cargo as you don't generally need much nesting, but anything with depth should use JSON. It's the perfect format for clearly displaying hierarchy.
  - okanat 2y ago
    It works only for trivial projects that are compiled in a roughly up-to-date and popular environment. Custom distros, vendored forks, closed-source software, firmware projects etc. all end up with hairy Cargo files. A systems language should recognize handling complexity gradually is a part of one of its use cases.
zahlman 2y ago
It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be: a = { b = [ { x = 1 } ], y = 2 } (And yes, that can be the entire document; you can have an inline table before the first table header.) Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway. But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time). I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.