Live data from Hacker News

Toml: Tom's Obvious, Minimal Language

github.com

61–70 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#62
Just dropping a useless comment to say thanks! Between Tom's work on Github, Jekyll, and TOML, I think he has influenced a vast amount of developers!

For the projects I've used TOML on, it was a nice breath of fresh air and a terrific improvement over JSON (still mad about JSON's lack of comments). Simplicity wins!

Re: Toml: Tom's Obvious, Minimal Language

#63

Just dropping a useless comment to say thanks! Between Tom's work on Github, Jekyll, and TOML, I think he has influenced a vast amount of developers! For the projects I've used TOML on, it was a nice breath of fresh air and a terrific improvement over JSON (still mad about JSON's lack of comments). Simplicity wins!

It's never useless to say thanks! I really appreciate your kind words, it's the fuel that powers a lot of open source. Keep it up!

Re: Toml: Tom's Obvious, Minimal Language

#64
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

Hi Tom. Dave here. I like a lot of the features in TOML, but I'm curious, can I have a pony? (Folks downvoting, PLEASE JUST LET PEOPLE HAVE JOKES EVERY NOW AND THEN)

Toml is better than a pony. Proof: http://toml.versus.horse

Re: Toml: Tom's Obvious, Minimal Language

#65
Funny enough, I learned how to/started to use TOML today. I was running some [redacted] experiments using a .pyc compiled script and wanted to experiment with parameters -- but then I had to compile the script again and again.

Enter TOML: I can paste a bunch of "var_x = 2"-type statements (there's like 50) directly from Python, read them as a dictionary and find-replace all appearances in like 5 minutes while I'm waiting for an Uber.

Thanks Tom!

Re: Toml: Tom's Obvious, Minimal Language

#66

Earlier quoted context omitted.

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.

Re: Toml: Tom's Obvious, Minimal Language

#67
post #43
post #30

Originally, I was fully on board with the homogeneous array requirement but its recently started causing me pains. Homogeneous arrays can come in the following forms - Shallow, literal type (a list of lists, regardless of the nested lists contain) - Full, literal type (a list of dicts of strings) - Logical type There are many times where a list is the best type for my data but I want to take advantage of logical type…

Homogenous arrays are partly to make implementations easier, and because if you really need that flexibility, you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness. I'm not sure I understand your complaint, though, can you give me another example of how it's biting you in real life?

> you can always use an array of inline tables, which has the benefit of giving each sub-element a name, hopefully increasing the obviousness

Except the name would be duplicated with the content I'm storing.

As for an example, its effectively Cargo. My use case is very similar (dependency reporting) but my content is slightly different (as I said, the value would effectively duplicate the key)

Re: Toml: Tom's Obvious, Minimal Language

#69
post #10

Hey, Tom here (creator of TOML). Fun to see TOML on HN again! Since I first wrote a (mostly) joke proposal for TOML 5 years ago, TOML has been adopted by a number of prominent projects such as Cargo, Hugo, Pipenv, and others. TOML is especially well suited for projects that need a simple configuration file that maps unambiguously to a hash table. There are still some weaknesses in TOML that make it non-optimal for la…

> There are still some weaknesses in TOML that make it non-optimal for large, complex config

May be the config shouldn't be large and complex in the first place?

My biggest question is, why hasn't TOML used much more widely or becoming de facto standard? Am I missing something obvious?

Re: Toml: Tom's Obvious, Minimal Language

#70

Funny enough, I learned how to/started to use TOML today. I was running some [redacted] experiments using a .pyc compiled script and wanted to experiment with parameters -- but then I had to compile the script again and again. Enter TOML: I can paste a bunch of "var_x = 2"-type statements (there's like 50) directly from Python, read them as a dictionary and find-replace all appearances in like 5 minutes while I'm wai…

Awesome, sounds like the perfect use case for TOML!
Post reply on HN