6 ms·

I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works

gnuvince 8y ago
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
- cies 8y ago
  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.
  - wvh 8y ago
    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".
    - mojombo 8y ago
      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.
  - adamch 8y ago
    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.
  - laumars 8y ago
    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.
- laumars 8y ago
  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.
  - freyir 8y ago
    > 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...
    - deckar01 8y ago
      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.
    - notheguyouthink 8y ago
      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.
  - unethical_ban 8y ago
    https://github.com/toml-lang/toml#array-of-tables https://github.com/toml-lang/toml#array-of-tables Still there FWIW.
- krapp 8y ago
  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]
- agumonkey 8y ago
  indicates an 'open' array ?
  - gnuvince 8y ago
    An array of dictionaries. In JSON, my example becomes: { "designers": [ {"name": "Guido", "lang": "Python"}, {"name": "Larry", "lang": "Perl"} ] }
    - mlthoughts2018 8y ago
      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.
      - agumonkey 8y ago
        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)
        mlthoughts2018 8y ago
        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.
- mojombo 8y ago
  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.
  - ben509 8y ago
    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 https://github.com/pypa/pipfile#pipfile
    - mojombo 8y ago
      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.
fastball 8y ago
I'm more a fan of YAML. "YAML Ain't Markup Language"
- clhodapp 8y ago
  TOML and YAML both have kinda weird names because both were initially incorrectly said to be a "markup language" and then subsequently renamed. The original names were "Yet Another Markup Language" and "Tom's Own Markup Language".

To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl

cies 8y ago
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.
- wvh 8y ago
  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".
  - mojombo 8y ago
    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.
- adamch 8y ago
  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.
- laumars 8y ago
  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.
laumars 8y ago
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.
- freyir 8y ago
  > 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...
  - deckar01 8y ago
    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.
  - notheguyouthink 8y ago
    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.
- unethical_ban 8y ago
  https://github.com/toml-lang/toml#array-of-tables https://github.com/toml-lang/toml#array-of-tables Still there FWIW.
krapp 8y ago
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]
agumonkey 8y ago
indicates an 'open' array ?
- gnuvince 8y ago
  An array of dictionaries. In JSON, my example becomes: { "designers": [ {"name": "Guido", "lang": "Python"}, {"name": "Larry", "lang": "Perl"} ] }
  - mlthoughts2018 8y ago
    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.
    - agumonkey 8y ago
      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)
      - mlthoughts2018 8y ago
        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.
mojombo 8y ago
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.
- ben509 8y ago
  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 https://github.com/pypa/pipfile#pipfile
  - mojombo 8y ago
    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.

fastball 8y ago

I'm more a fan of YAML. "YAML Ain't Markup Language"

clhodapp 8y ago
TOML and YAML both have kinda weird names because both were initially incorrectly said to be a "markup language" and then subsequently renamed. The original names were "Yet Another Markup Language" and "Tom's Own Markup Language".