3 ms·

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 rat

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" Than one 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" } } Semantically, I just find the first one clearer and more intuitive. (The links are really only the dubious part.) The equivalent YAML doesn't look bad: 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 ...but the significant whitespace makes it somewhat more fragile, particularly in those pesky links.

mlthoughts2018 8y ago
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.

mlthoughts2018 8y ago

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.