Earlier quoted context omitted.
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 matte…
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…
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.