Live data from Hacker News

Toml: Tom's Obvious, Minimal Language

github.com

81–90 of 204 posts

Re: Toml: Tom's Obvious, Minimal Language

#81

Earlier quoted context omitted.

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 matte…

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.

Re: Toml: Tom's Obvious, Minimal Language

#82
post #75
post #67

Earlier quoted context omitted.

> 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)

Oh, you mean you want something like: list = [ "1.0", "2.7", { version = "1.4", path = "..." }, "9.9", ] Is that correct?

Something akin to that, yes.

Re: Toml: Tom's Obvious, Minimal Language

#83
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…

So like YAML, TOML ain't markup language either, despite the recursive acronym and the "ML" suffix. If your name was Mark instead of Tom, would you have named it MARKML, and would it still not be markup language?

Re: Toml: Tom's Obvious, Minimal Language

#84
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)

You aren't going to change what people around here like. And complaining about downvotes usually just attracts more.

If you think that your brand of funny is worth braving people's disapproval, do it knowing what the reaction is going to be. If you don't like people disapproving, then go elsewhere, or engage here in a way that people prefer.

Re: Toml: Tom's Obvious, Minimal Language

#85

I just started a rust project and so had to learn TOML since that's what the package manager (and a lot of the ecosystem) uses. For some reason, though, I just struggle with the syntax. It says it's "obvious" but it wasn't to me. I think it says something that the README is full of "this TOML would be represented like this JSON", to help you understand what's going on. Every time I saw that, I was like "oh, now I get…

Yeah, most of TOML looks good, but the .INI style [table] and even wierder the [[table-array]] thing seems like they were trying to hammer a square peg into a round hole for the sake of having config files that look like INIs.

Re: Toml: Tom's Obvious, Minimal Language

#86
post #46

I didn't know about TOML until I started using Hugo. I've been using YAML and TOML and I find both have their merits, especially for their simplicity. TOML looks like the classic INI file, and is fairly easy to use/learn. I've been trying to move toward TOML for everything. YAML is nice, but I had to be careful about white-space significance and also translation of "YES","NO", etc. https://arp242.net/weblog/yaml_prob…

Absolutely. That's what I mean about TOML mapping unambiguously to a hash table. Strings in TOML are always quoted. There is no fuzzy interpretation of things like YES and NO. That way madness lies. I also am not a fan of meaningful whitespace, which is why TOML doesn't do that. Glad you're finding TOML useful, good luck on your projects!

> There is no fuzzy interpretation of things like YES and NO

I think the big problem is that YAML is dynamically typed. If I had schema-enforced config files, I'd be perfectly happy to say that for boolean typed data all the values of YES and NO and ON and OFF and T and F and 0 and 1 can all be reasonably interpreted as a Boolean True and False. The problem happens when a string-typed or integer-typed member can also have their ON value interpreted into Boolean TRUE.

Re: Toml: Tom's Obvious, Minimal Language

#87

Earlier quoted context omitted.

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 matte…

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.

Re: Toml: Tom's Obvious, Minimal Language

#88
post #85

I just started a rust project and so had to learn TOML since that's what the package manager (and a lot of the ecosystem) uses. For some reason, though, I just struggle with the syntax. It says it's "obvious" but it wasn't to me. I think it says something that the README is full of "this TOML would be represented like this JSON", to help you understand what's going on. Every time I saw that, I was like "oh, now I get…

Yeah, most of TOML looks good, but the .INI style [table] and even wierder the [[table-array]] thing seems like they were trying to hammer a square peg into a round hole for the sake of having config files that look like INIs.

Backwards-compatibility with ini is in my opinion one of the more powerful aspects of TOML which help adoption. Kinda like how UTF8 is ASCII-backcompatible.

Re: Toml: Tom's Obvious, Minimal Language

#89
post #71

Earlier quoted context omitted.

1. Yea the goal would be some kind of validation at parsing time. I'm not super familiar with TOML parsing, but there must be error cases in the implementations, so it seems like using `\` on UNIX systems, for example could return an error. The only hard part about this I see is distinguishing paths from strings syntactically without making TOML overly complex. 2. So basically, the majority of people don't want to ty…

Backslashes are valid characters in a POSIX filesystem, but they don't indicate a directory.

Yeah...rather than validating paths, the better use case is probably normalizing them so that you don't need platform-specific configuration files. Being able to write:

static-files = path/to/static/files

And have it work on all platforms gives a distinct advantage over specifying paths as strings.

Post reply on HN