This JSON is vastly more readable, frankly. It’s so clear what container type “designers” refers to, and I can read directly what data structures the elements are. I can’t do that in Toml. Unless I just happen to remember some rote memorized convention for what the syntax unpacks into, there’s no way to tell by looking at Toml code. IMO this ought to be priority number one for any utility language like this. No matter what brevity of other syntax there might be, this lack of direct expression of the data structures is too much of a problem.
This JSON is also much more readable than the “dot attribute” Toml syntax too, which I think is one of the least intuitive and hardest to read ways of creating nested data structures, certainly vastly less readable than the equivalents in YAML or JSON.
I’ve never understood why anyone would say Toml is easier to read than YAML or JSON. It’s drastically harder to read and more confusing.
I think you're focusing on TOML's weakest case here. I think for a lot of configuration files, TOML is going to be easier to read and write. Personally, I'd rather have a configuration file that looks like this:
[site]
name = "My Great Website"
url = "https://example.com"
author = "Watts Martin"
email = "foo@bar.com"
links = [
{ name = "tom", url = "http://tom.example.com" },
{ name = "bob", url = "http://bob.example.com" }
]
[database]
server = "localhost"
username = "dbuser"
password = "dbpassword"
Actually, even here in your extended example, the JSON is the easiest to read. For durable files that will be read much more than written, saving a few newlines or keystrokes is super irrelevant, but JSON gives such explicit understanding of the data structures and nesting, which IMO is really confusing and hard to understand in Toml.
I can agree Toml is sometimes better than YAML, but I cannot agree it is better than JSON. For me JSON is so simple, so easy to read, it has the nice feature of preventing comments and multi-line strings to keep things extremely simple and to enforce that documentation about the values in the file has to be located outside the file, as it absolutely should (documentation should be at the site that uses the config/param file, not inside it).
Plus, I find JSON indentation to be a real joy to assist with reading and seeing the nested structure. That indentation is optional in Toml, but I think pretty much always the use of that indentation ought to be enforced as a convention for people using Toml. Lacking the indentation is really not good for config / parameter files.
Nesting has locality value, which is often desireable.. but as I said, the [[toml]] syntax yields open arrays, it seems you can define thing in multiple passes (which can be harmful but may also be a need once in a while)
