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

111–120 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#111

Post by Spivak »

rand_flip_bit wrote: post #109
Spivak wrote: post #106

Earlier quoted context omitted.

As much as I think it's annoying I think no trailing commas enforces good coding hygiene and basically forces you to use a real encoder rather than as hoc string manipulations.

This is such a bad take

Care to like, elaborate? Stopping people from doing brittle stuff like

    print("{")
    for elem in list:
        print('"key": "value",')
    print("}")
seems like immediate worth.

Re: TOML: Tom's Obvious Minimal Language

#112

Post by NoahKAndrews »

veidr wrote: post #86
nikeee wrote: post #83

Earlier quoted context omitted.

I like the idea of JSON5, but it allows a bit too much in my opinion. For example, why add the single quote? Why hexadecimal identifiers?

JSON is trash and should never be used in any human-interfacing context, so I'm super skeptical that there's any utility in trying to fix it; that would just delay its demise, to the detriment of humankind. But if you did want to fix JSON, the yes, trailing commas and comments are the absolute minimum bar, but single quote is actually probably the the third absolute must-fix. The reason is just that so much JavaScrip…

Prettier defaults to double quotes.

I'm curious what you have against Prettier.

Re: TOML: Tom's Obvious Minimal Language

#113

Post by matsemann »

IshKebab wrote: post #96
camgunz wrote: post #45

Rather than a JSON replacement, I like TOML as a YAML replacement. It's a lot simpler, I'm not confused by things not having a preceding dash, indentation isn't significant, etc.

I disagree. TOML is an INI replacement. They both suck at nested structures but are good if you just have a load of top level sections containing simple key-values. YAML on the other hand is just as good at any nesting depth. I mean it's pretty awful at all depths, but the act of nesting doesn't make it any more awful.

I spent a whole day debugging an issue because an extra - dash in yaml.

I had something like

  rules:
   - name: Only allow X
   - condition: ip=123
The - in front of condition of course makes a new list element. So I now had 2 rules. One with no conditions and a name, and an unnamed one with conditions. Since they are or'ed together everything for some reason I couldn't figure out went through, as I thought I had a single rule..

I hate yaml.

Re: TOML: Tom's Obvious Minimal Language

#114

Post by mst »

ohazi wrote: post #63
SPBS wrote: post #10

JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

53 bit integers should be enough for anyone

(in practice for config it usually is but enforcing it is horribly patchy)

Re: TOML: Tom's Obvious Minimal Language

#115

Post by marcosdumay »

Spivak wrote: post #106
marcosdumay wrote: post #89

Earlier quoted context omitted.

Trailing commas a very highly impactful to the users, and trivial to the language writers. The 123_456 syntax comes close to that, but is much less impactful. None of those will make the language hard to parse.

As much as I think it's annoying I think no trailing commas enforces good coding hygiene and basically forces you to use a real encoder rather than as hoc string manipulations.

You are talking about data transfer encoding. Configuration languages are a completely different beast.

Re: TOML: Tom's Obvious Minimal Language

#116

Post by hnlmorg »

analog31 wrote: post #70
conaclos wrote: post #27

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…

Just to add one more feature request... ;-) Comments are preserved when you read a file, change some of its contents, and write it back out again.

I have zero issues if parsers choose to do this but I wouldn’t argue that it shouldn’t be a required part of the specification. If comments need to be preserved then they’re part of the schema and should be a (for example) string field rather than comment.

Re: TOML: Tom's Obvious Minimal Language

#117

Post by grncdr »

alpaca128 wrote: post #46

TOML is nice as a kind of extended .ini format but I don't like the approach to avoiding nested elements. I prefer KDL. It's like XML but with almost zero syntax. Probably not always the best idea because it's so niche but it's just really simple while having all the basics like comments and multiline strings.

KDL (assuming you mean https://kdl.dev/) looks great, thanks for mentioning it.

Re: TOML: Tom's Obvious Minimal Language

#118

Post by somewhereoutth »

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.

But JSON is strings. So 123.4 is essentially "123.4" but with the indication that it is supposed to be semantically a numerical value.

Re: TOML: Tom's Obvious Minimal Language

#119

Post by IshKebab »

matsemann wrote: post #113
IshKebab wrote: post #96

Earlier quoted context omitted.

I disagree. TOML is an INI replacement. They both suck at nested structures but are good if you just have a load of top level sections containing simple key-values. YAML on the other hand is just as good at any nesting depth. I mean it's pretty awful at all depths, but the act of nesting doesn't make it any more awful.

I spent a whole day debugging an issue because an extra - dash in yaml. I had something like rules: - name: Only allow X - condition: ip=123 The - in front of condition of course makes a new list element. So I now had 2 rules. One with no conditions and a name, and an unnamed one with conditions. Since they are or'ed together everything for some reason I couldn't figure out went through, as I thought I had a single r…

Yeah I've had this happen to me too. Truly awful format. I think the only reason it has caught on is because it has multiline strings, which are usually not great in other formats. Of course YAML fucks that up too by having a gazillion different kinds of multiline strings, distinguished only by impossible to remember symbols. But it does at least have them.

Re: TOML: Tom's Obvious Minimal Language

#120

Post by IshKebab »

arp242 wrote: post #99
IshKebab wrote: post #94

Earlier quoted context omitted.

How do you know which version you are using though?

You don't; you check the library or application's documentation. TOML went through some substantial changes in the past with 0.4, 0.5, and 1.0. As I mentioned in my other comment[1], it's not ideal, but it is what it is. I wouldn't be surprised if 1.1 would be the last version. Maybe there will be a 1.2 to clarify some things, but I wouldn't expect any further major changes. [1]: https://news.ycombinator.com/item?id=…

> You don't

Great. Very obvious.

Post reply on HN