Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

Post reply on HN
Print view View original

151–160 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#151

Post by OtomotO »

Simran-B wrote: post #144
friend_and_foe wrote: post #103

I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but…

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

Yaml is incredibly complex. KISS

Re: TOML: Tom's Obvious Minimal Language

#152

Post by Waterluvian »

crdrost wrote: post #149
dijit wrote: post #143

Earlier quoted context omitted.

You wrote this as if it’s a defense but honestly I feel even more terrified of JSON numbers now than I was before entering this thread, and before reading your comment. Not following a set standard is undefined behaviour, leaving it up to the implementation is a large problem in other areas of computer science. Such as C compilers.

Yes but this is a necessary limitation for all human readable numbers. The context decides what to deserialize into and different contexts/languages will choose bigint vs i64 vs u64 vs i32 vs double vs quad vs float, whatever is convenient for them. Heck, some of them will even choose different endian-ness and sometimes it will matter. I still remember the first time I dealt with a Java developer who was trying to se…

It also means you can use JSON for incredibly high precision cases by making your parser parse them into a Decimal format. You couldn’t do this if you specified these limitations into the language.

Edit: Omg that story. Eep. I guess if someone provided too-large numbers in a JSON format, you could use a custom parser to accept them as strings or bigints. Still, that must have not been a fun time.

Re: TOML: Tom's Obvious Minimal Language

#153

Post by monsieurbanana »

dijit wrote: post #143
Waterluvian wrote: post #137

Earlier quoted context omitted.

JSON’s numbers are not IEEE-754. They’re numbers with an optionally infinite number of decimal places. It’s up to a parser to handle it. Python can parse these into integers if there isn’t a decimal place. It’s in the name, but be careful not to get confused with JSON being JavaScript.

You wrote this as if it’s a defense but honestly I feel even more terrified of JSON numbers now than I was before entering this thread, and before reading your comment. Not following a set standard is undefined behaviour, leaving it up to the implementation is a large problem in other areas of computer science. Such as C compilers.

You could invent a language that represents data that is very explicit about having integers, the implementation in javascript would still spit out floating values, because that's all the language has.

So either you don't target javascript (which would be a bit silly in the case of JSON), or you go the other way and forbid integers, even in languages that do support them. Which is also kind of silly.

Ultimately the real issue is that javascript doesn't have integers and if you're interacting with it, you need to be aware of that, JSON or not.

Re: TOML: Tom's Obvious Minimal Language

#154

Post by MrJohz »

Simran-B wrote: post #144
friend_and_foe wrote: post #103

I use TOML and JSON for everything. I like them both quite a bit. TOML gets a lot of criticism for not being JSON and JSON gets a lot of criticism for... not being entirely fit for it's stated purpose. However, they're both fantastic if you use them for what they're good at: TOML for human readable configurations that you expect a user to modify, JSON for representing data that a machine will read all of the time but…

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environments. If a user is ever able to submit data that is interpreted by a YAML parser, they can run arbitrary code, and potentially even commands.

The fixes for these are both fairly well known (always quote strings and keys, use safe_load or an equivalent API), but it's very easy to make a mistake.

TOML, by contrast, is much simpler - strings are strings are strings, they must always be quoted but other than that behave pretty much as expected. Similarly, there is no mechanism by which a TOML file can instruct the parser to execute arbitrary code as part of deserialisation, which makes it (a) a lot simpler, and (b) a lot safer.

Re: TOML: Tom's Obvious Minimal Language

#155

Post by enriquto »

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their jsons, xml2'd their xmls and so on, thus pruning the universal dependency tree by a considerable amount.

Re: TOML: Tom's Obvious Minimal Language

#156

Post by [deleted] »

Spivak wrote: post #105
josephcsible wrote: post #77

Earlier quoted context omitted.

You can store arbitrary precision numbers in JSON. The spec explicitly doesn't lock you into floats or any other specific number format.

Only if you are both sides of the transmission. If you're sending JSON to code you didn't write you will eventually get bitten by software lossy re-encoding. Lots of places use strings for this reason. It's like API's that mess up the semantics of PUT/GET so implementing idempotency is extra annoying.

[deleted]

Re: TOML: Tom's Obvious Minimal Language

#157

Post by rfoo »

enriquto wrote: post #155

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…

--flagfile gets me really far but to be fair it sucks when you need nested kv

Re: TOML: Tom's Obvious Minimal Language

#158

Post by enriquto »

rfoo wrote: post #157
enriquto wrote: post #155

Graybeard opinion: all of toml, yaml, xml, json, kdl, etc., are ridiculously over-engineered for simple configuration files. You can nearly always fulfill all of your needs with a simple two-column text file of key=value pairs that can be parsed by a trivial call to fscanf(3) or whatever your laguage supports (yes, even correctly discarding comments). The world would be a better place if people just gron'd their json…

--flagfile gets me really far but to be fair it sucks when you need nested kv

just use longer keys (with an ad-hoc separator, if you want)

Re: TOML: Tom's Obvious Minimal Language

#159

Post by rascul »

lexicality wrote: post #20
the_mitsuhiko wrote: post #17

Earlier quoted context omitted.

There is a secret third thing called "feature not in file" and most TOML implementation encourage it as "key not in file" is typically returned as `null` or `None`. That's how so many TOML files in practice end up with all these secret values. It's also particularly odd in lists where I have seen `["foo", "bar", {}]` show up in the real world with `{}` being used as a replacement value for null.

In my experience (Python and Rust) missing keys are errors, not silently converted to None: In [1]: example = {"foo": None} In [2]: print(example["foo"]) None In [3]: print(example["bar"]) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) Cell In[3], line 1 ----> 1 print(example["bar"]) KeyError: 'bar' In [4]: print(example.get("bar", "sensible defa…

> In my experience (Python and Rust) missing keys are errors, not silently converted to None:

In Rust it's possible to deserialize to an Option.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: TOML: Tom's Obvious Minimal Language

#160

Post by daveevad »

MrJohz wrote: post #154
Simran-B wrote: post #144

Earlier quoted context omitted.

I don't understand the appeal of TOML. Why not use YAML instead? Seems a lot more "obvious" to read and write to me. And it's the best I know that is strong in both, human and machine readability.

YAML has a lot of extra stuff going on that can cause accidents if you don't take care. The classic example is the "Norway problem" where "no" (the country code for Norway) is parsed as "false" instead. If "no" is used as a key, this can cause the Norwegian data to disappear or to throw strange errors on load. The other big issue is that, by default, it allows relatively unrestricted code execution in many environmen…

Someone at work recently got bit by unexpected YAML parsing a git commit hash that contained a substring which was a valid number in scientific notation (IIRC 5e38031).
Post reply on HN