[deleted]
TOML: Tom's Obvious Minimal Language
31–40 of 229 posts
Re: TOML: Tom's Obvious Minimal Language
#32Earlier quoted context omitted.
> There is a big difference between configuration language formats and programming languages. In general: I agree. But configuration formats (including TOML) also need to map well to programming languages, so you can't seem them as entirely separate. One argument against Null is that it doesn't elegantly map to a data structure in all programming languages.
> One argument against Null is that it doesn't elegantly map to a data structure in all programming languages. TOML has plenty of constructs that don't map well to many languages. Plenty of language implementations do not know how to work with the datetime type, some TOML implementations barf on objects in lists. In some TOML implementations you also end up with nulls showing up when certain empty table constructs ar…
> Plenty of language implementations do not know how to work with the datetime type
Right, and IMO datetime was a mistake to include in TOML.
Re: TOML: Tom's Obvious Minimal Language
#33Funny thing: TOML author/inventor calls it a mistake:
> TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read.
> I personally abandoned TOML and as such, I'm not planning on adding any new features
> If you're still reading, I'd like to put forth CSON as a format of choice.
https://github.com/avakar/pytoml/issues/15#issuecomment-2177...
Re: TOML: Tom's Obvious Minimal Language
#34I 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…
Among types and other useful properties, CUE supports everything you asked for. We're even considering adding a "data-only" mode to CUE which would be exactly what you asked for. https://cuelang.org
Is there any concise representation of the language spec? Similar to the spec of JSON [1].
Re: TOML: Tom's Obvious Minimal Language
#35I 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…
JSON as a computer-generated serialization format doesn't need any of those features. But for human-written configuration files, at the very least trailing commas and comments are basically a necessity. The question then is which features to pick beyond that (in my humble opinion, none), and how such a new standard would gain traction. JSON5, JSON6, JSONC all basically attempt to solve the latter problem by branding, but so far, mostly have failed.
It doesn't help that there's an insane amount of bike-shedding going on in this space. The people who have forked JSON5 to create JSON6 for example have created an endless amount of confusion over which standard to use, harming both of them. I think they might want to think really hard whether the inclusion of octal literals was really worth the hostile fork.
Re: TOML: Tom's Obvious Minimal Language
#36I'm puzzling over where I would use this sort of thing, over say Json, or simple xml, and I realise that it's mostly useful in cases where you're expected to edit the configuration in a text editor. That's not something I come across a lot - all my software (that I use) has a visual interface, and so raw editing of text/config files is not something we do. So context really comes into play here. I can see how this wo…
I moved some config files from json to yaml. Maintaining the documentation became a lot easier, because before I had a document describing every config option, which I had to maintain separately, instead now I have comments in the config file itself.
Note that now you have "the Norway problem" instead. https://hitchdev.com/strictyaml/why/implicit-typing-removed/
There's a whole spectrum of config formats including JSON, JSON5, strict YAML, YAML. It's quite messy.
Re: TOML: Tom's Obvious Minimal Language
#37My main issue with TOML is precisely described in the homepage example:
[servers]
[servers.alpha]
is error prone. An sub heading shouldn't need to know about its parent, much less to have to copy it entirely.
Re: TOML: Tom's Obvious Minimal Language
#38JSON 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
Multi-line strings are another weakness. Sometimes you don’t\nwant\nto\nwrite\nthis\nway.
Re: TOML: Tom's Obvious Minimal Language
#39Not to be confused with the Tom Programming Language[0], a kind of early 2000s proto-Swift.
Re: TOML: Tom's Obvious Minimal Language
#40Funny thing: TOML author/inventor calls it a mistake: > TOML is a bad file format. It looks good at first glance, and for really really trivial things it is probably good. But once I started using it and the configuration schema became more complex, I found the syntax ugly and hard to read. > I personally abandoned TOML and as such, I'm not planning on adding any new features > If you're still reading, I'd like to pu…
> Funny thing: TOML author/inventor calls it a mistake
You mean the author of this specific python implementation, or did Tom Preston-Werner ever disavow it?