Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

21–30 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#21

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…

This is a table.

Let's see it do a tree. (And not an adjacency matrix. That's cheating.)

Re: TOML – Tom's Obvious, Minimal Language

#23

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…

It all depends on context. Honestly, I've rarely (never?) needed to store GUIDs, IP addresses, or byte arrays in a configuration file. So that's not as common of a situation as you're thinking - maybe for your experience, but there are many different uses for configuration. The example you give would suck in any configuration file format, and honestly I don't believe it belongs in a configuration file - I'd put it in…

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.

Re: TOML – Tom's Obvious, Minimal Language

#25
post #23

Earlier quoted context omitted.

It all depends on context. Honestly, I've rarely (never?) needed to store GUIDs, IP addresses, or byte arrays in a configuration file. So that's not as common of a situation as you're thinking - maybe for your experience, but there are many different uses for configuration. The example you give would suck in any configuration file format, and honestly I don't believe it belongs in a configuration file - I'd put it in…

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 networking library api calls also take strings as arguments for this reason. Not saying its a better solution, but there times when either an IP or a string hostname should be acceptable.

I've never had to use it, but Qt does have a hostname class, for an example of what such a dtype looks like. The class explicitly handles conversion for you:

https://doc.qt.io/qt-5/qhostaddress.html

Re: TOML – Tom's Obvious, Minimal Language

#26

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've been using TOML recently and what displeases me most is that almost all string values need to be quoted.

Re: TOML – Tom's Obvious, Minimal Language

#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.

Re: TOML – Tom's Obvious, Minimal Language

#28

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…

Though I'll agree that I don't love the name "table". I think it's referring to the kind of table you might see in an instruction booklet or something, with keys on the left and their values on the right, but the possible confusion with database tables seems not great.

Re: TOML – Tom's Obvious, Minimal Language

#29
post #19

I hope this catches on some more. I'm tired of being bitten by all the issues that I encounter with yaml configs.

What are these issues? I've been using YAML comfortably for years

This link has a decent overview: https://www.arp242.net/yaml-config.html

There's also the NO/Norway problem (although it seems this instance of the problem may be fixed if you're always using newer versions): https://allan.reyes.sh/programming/2018/06/20/The-YAML-NOrwa...

Re: TOML – Tom's Obvious, Minimal Language

#30
post #13

Of configuration file formats, TOML is my favorite. It hits the right balance of power and simplicity, it's been able to handle my needs with minimal effort and fuss. I tried Python's INI for configuration, but it was both too simple and too complex at the same time, very frustrating. YAML is a nightmare, the formatting is way too easy to get wrong and accidentally break your configuration. JSON is too strict/simple.…

I recently wrote a TOML parser in Idris2. It's a cool language, but has some quirks. For me, it's that it's just a simple KV store with some sugar (that's nice!) but it also means that a lot of information is lost forever in parsing. For example, these two documents are strictly identical: [info] name = { first="bob", last="jones" } and info.name.first="bob" info.name.first="jones" This can be seen as a positive (it'…

Can you expand on the negatives? I don't think I understand what you mean.
Post reply on HN