Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

31–40 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#32
post #10

I'm personally sick of yet-another-config-formats. Why did designing metaformats become cool? They all have warts because using the same symbolic notation for data and structure leads to encoding issues that have cognitive overhead. So instead of getting used to the pratfalls involved in making mistakes in one format/library set, we can do it in a whole bunch of different ones. And of course if anyone uses the new fo…

> I'm personally sick of yet-another-config-formats. Why did designing metaformats become cool?

I can't seem to find a date for it, but I think TOML is pretty old, so probably predates a lot of these YACFs.

I think that the problem is that it's such an easy workflow:

1. No existing config format is perfect. Look at this should-be easy thing I want to do that isn't easy!

2. Create a new format that makes the desired should-be easy thing actually easy.

If you have one or two pain points, then it's really easy to address them, and your life gets so much better for a little while. If you're lucky and you're a good YACF designer, then your life gets so much better for quite a while—and, by the time you realise why the design isn't perfect, you're already invested in it.

Re: TOML – Tom's Obvious, Minimal Language

#33
post #25
post #23

Earlier quoted context omitted.

Every server config ever requires an IP address entry which in itself is a non trivial proportion of all the user edited config files in the world.

But surely strings are valid? Unless you want some kind of static type checking/linting for eg an ipv4 vs ipv6 key? Strings are very portable as well (POD). Plenty of real world applications use static hostnames and rely on DCHP to assign IPs. When you have systems that can fail hard and you need to replace a NIC, it saves having to update either a ton of config files, router configs, or your hosts file(s). Most netw…

IP is a configuration option for most server software, it’s just that it usually needs to be set to 0.0.0.0 and that is the default anyway so most admins just leave it out.

Re: TOML – Tom's Obvious, Minimal Language

#34
“Obvious” is subjective. I find TOML to be remarkably confusing and surprising and UNobvious, whereas YAML makes perfect sense to me, even though plenty of folks hate it. Essentially, the name is pretty obnoxious in multiple ways, given that it’s basically just an extension of the long-established INI format.

Re: TOML – Tom's Obvious, Minimal Language

#35
post #27

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

I think terseness and readability are often at odds past a certain point, and TOML seems to optimize for readability at the expense of terseness. E.g., having to specify column names again and again is tedious to write, but makes the file easier to read and modify safely.

Yeah, I think toml is great short/simple config files, yaml is good for medium length/complexity, and I have yet to see anything that’s not painful for long config files.

Re: TOML – Tom's Obvious, Minimal Language

#36

I still don't understand why the Python steering committee decided to switch to this format for package configuration instead of the perfectly serviceable and existing setup.cfg. Packaging is already a pain to setup, now you gotta learn three (3) different ways to do it (if only to translate from one to the next) because everyone's split. The choice doesn't even matter very much, just settle on something whatever it…

There's not much to learn. It's basically .ini on steroids.

It's not that it's hard. It's that it's different, and every difference has a cost. IMHO, and in the OP's opinion, the benefit of TOML for packages isn't worth the mental cost of having to know about three configuration methods.

Re: TOML – Tom's Obvious, Minimal Language

#37
post #17

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

> GUIDs, IP Addresses, and byte arrays. In what situation is it not suitable to store these as strings, byte arrays as unbounded hex-encoded integers? 0xabcdef123400000000 As for your csv-example, I’d propose that if you have multi-value entries in a list like that large enough that it becomes unwieldy to repeat the property names every time (like in JSON or yaml), it really doesn’t belong in static configuration but…

It's about strong typing. I detest stringly-typed programming.

If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String".

This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats:

    {123e4567-e89b-12d3-a456-426652340000}
    (123e4567-e89b-12d3-a456-426652340000)
    123e4567-e89b-12d3-a456-426652340000
    123e4567e89b12d3a456426652340000
    urn:uuid:123e4567-e89b-12d3-a456-426655440000
Similarly, with IPv6 all of the following are the "same" address, but if encoded as a string it's hit-and-miss if the far end can properly handle all of the variants:

    fe80:0000:0000:0000:01ff:fe23:4567:890a
    fe80:0000:0000:0000:1ff:fe23:4567:890a
    fe80:0:0:0:1ff:fe23:4567:890a
    [fe80::1ff:fe23:4567:890a]
    fe80::1ff:fe23:4567:890a
    fe80::1ff:fe23:4567:890a%3
Similarly, for your hex-encoded binary example, you'd be shocked at how rare it is for programming languages to provide a "hex-string-to-byte-array" decoding function. If you roll your own, it'll be about 10x less efficient than something done properly using SIMD instructions.

Just recently I had to deal with Azure Resource Manager Templates, where even the distinction between numeric and text types has been eroded. There's several number fields that must be a string. There are also numeric fields that weirdly accept a string, but only if it is an ARM template expression that evaluates to a string containing a number at runtime.

Ugh...

Re: TOML – Tom's Obvious, Minimal Language

#39

I still don't understand why the Python steering committee decided to switch to this format for package configuration instead of the perfectly serviceable and existing setup.cfg. Packaging is already a pain to setup, now you gotta learn three (3) different ways to do it (if only to translate from one to the next) because everyone's split. The choice doesn't even matter very much, just settle on something whatever it…

There's not much to learn. It's basically .ini on steroids.

What confuses me is why there isn't a toml module in the standard library.

Re: TOML – Tom's Obvious, Minimal Language

#40
YAML and TOML wouldn't have been necessary if JSON had been slightly more expressive. If JSON had

  * comments
  * bareword (not double quoted) object key names
it'd be a much more suitable configuration file format for everything, and I don't think we'd see the motivation to make things like TOML and YAML.
Post reply on HN