I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works
I'm more a fan of YAML.
"YAML Ain't Markup Language"
Toml: Tom's Obvious, Minimal Language
11–20 of 204 posts
Re: Toml: Tom's Obvious, Minimal Language
#12I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
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]Re: Toml: Tom's Obvious, Minimal Language
#13Re: Toml: Tom's Obvious, Minimal Language
#14Earlier quoted context omitted.
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] 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.
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.
Re: Toml: Tom's Obvious, Minimal Language
#15Earlier quoted context omitted.
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.
Re: Toml: Tom's Obvious, Minimal Language
#16(2013)
v0.5.0 is a new release! Changelog: https://github.com/toml-lang/toml/blob/master/CHANGELOG.md#0...
Yes, we just released it two days ago! I know v1.0.0 has been a long time coming, but it's important to me that we get it right, as specs have a very long-lasting impact (much more so than a specific version of a library). We are indeed working hard towards a proper 1.0 though!
Re: Toml: Tom's Obvious, Minimal Language
#17Earlier quoted context omitted.
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
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…
> 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...
Re: Toml: Tom's Obvious, Minimal Language
#18For more complex config, I highly recommend HOCON (https://github.com/lightbend/config/blob/master/HOCON.md), and its parser in Java (https://github.com/lightbend/config).
It feels like Scala (Lightbend is the company behind Scala) in the sense that there are 100 ways to achieve the same thing and having different levels of "code elegance", but for me it's a plus, since I'm a Scala fan.
Re: Toml: Tom's Obvious, Minimal Language
#19Earlier quoted context omitted.
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
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…
https://github.com/toml-lang/toml#array-of-tables
Still there FWIW.
Re: Toml: Tom's Obvious, Minimal Language
#20I never really questioned the name, TOML, but I guess "Tom's Obvious, Minimal Language" works
To me, there was nothing obvious about the double bracket syntax, e.g.: [[designers]] name = Guido lang = Python [[designers]] name = Larry lang = Perl
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.