Hacker News Reader

Comment by gnuvince | Hacker News Reader

To me, there was nothing obvious about the double bracket syntax, e.g.:

    [[designers]]
    name = Guido
    lang = Python

    [[designers]]
    name = Larry
    lang = Perl

View on HN

Yeah, it's not my favorite part either. We've made them mostly unnecessary by adding inline tables, but for heavy nesting of arrays of tables, you still need to use them, which is why I mentioned that there are still some weaknesses for large, complex config files. Hoping to make this better in 2.0.

In defense of double brackets, I first encountered TOML in pipenv[1], and just by experimenting found I could add another source. So they're reasonably obvious if you see them in an existing file.

[1]: https://github.com/pypa/pipfile#pipfile

Yeah, they're ok for very simple use cases, it's when you start having more than one level of nesting that things get a little crazy.

I agree about the double bracket syntax however I don't think that is part of the specification any more, instead nested structures use a dot notation inside single brackets. Both solutions do still feel like a hack though, but the dot notation is definitely less ugly.

That all said, for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML counterparts. If there is one thing I did like about Windows back when I used to run it, it was the syntax of INI files (which TOML was heavily influenced by).

Ultimately though, there is no perfect solution for all problems.

> for flatter schema's I do personally think TOML is more readable than it's JSON, YAML and XML

Yes. But for nested data, I find TOML becomes the least readable and I have to fall back to YAML or JSON.

Maybe we need just one more ML...

I disagree. The way JSON and YAML nest data with indentation forces data to be disconnected from it's property chain when there are multiple large items at each level. TOML seems to provide a solution to that by allowing deeply nested paths to be declare explicitly at the top level for each item. You get to choose how to split the paths into containers instead of being locked into a 1-to-1 tree structure.

Oh man, I can't disagree more.

I loathe YAML for readability. When I'm 2 pages down on a yaml tree I have no clue how many indents exist before what I'm working on. Likewise, when I scroll up, I quickly lose track of what the actual parent to the data I was working on is. I've found it to be an absolute mess.

JSON doesn't even fit for me, because it's not human intended (imo). Being able to document (comments) configuration is a requirement for me on any config language.

https://github.com/toml-lang/toml#array-of-tables

Still there FWIW.

Yeah, that's weird.

For the most part the language seems like a smarter slightly more flexible INI which I like (although there's no real standard for INI, most formats don't allow for nested arrays or tables,) but why embrace bracket notation for arrays, but not a keyed syntax with the same brackets for tables?

Something like this would have been be a lot cleaner to me:

    [designers]
    [name = Guido, lang = Python]
    [name = Larry, lang = Perl]

Yups. And making a whole datetime RFC part of the spec kind of broke with the "minimal" thing. But apart from that I totally prefer it over INF/YML/JSON/XML for many purposes.

I guess there's no way around that though, if you want dates to be first class members. Can't do "a bit of date".

We added a proper datetime type because the only thing worse than having one is not having one. If you had to supply a datetime as a string, every TOML file would have a different way of doing it, which is...not so obvious.

Excluding the datetime RFC in the name of minimalism would make the language much worse (coughjson). I feel like this is as simple as it could be, but no more.

Datetime does need to be part of the spec if you want your markup files portable otherwise every TOML parser might decode a date slightly differently. In that regard it is really no different to saying "01" (string) is different to 1 (integer) in terms of preserving your data's integrity.

indicates an 'open' array ?

An array of dictionaries. In JSON, my example becomes:

    {
        "designers": [
            {"name": "Guido", "lang": "Python"},
            {"name": "Larry", "lang": "Perl"}
        ]
    }

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.

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)

Sure, I only mean that the syntax for it in Toml is extremely hard to read. I personally just find JSON and YAML much, much easier to read.

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.

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.

Reply on news.ycombinator.com