Amazon's Ion format is decent, albeit not so long in the public domain, i believe
wow, thanks for that. Ion is really pretty. But I still can't shake it that curly brace delimiters are inappropriate for a configuration format.
Fear and Loathing in YAML
61–70 of 107 posts
Re: Fear and Loathing in YAML
#62I think I would genuinely be pretty happy with a well-supported extension of the JSON spec that allows comments. Even if it required an explicit start and end of the comment (/* ... */). I also can't say I want or need anchors/references from YAML, so I think that helps me be quite OK with using JSON. I appreciate the challenges of writing JSON, but also think it can be easier to spot issues if you have an editor tha…
I like Human JSON: https://hjson.github.io/
It has comments and accepts trailing commas.
Re: Fear and Loathing in YAML
#63TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…
In the future, everyone will write a markup language that will be the flavor of the quarter-hour, begetting a cottage industry of translation tools.
Actually, there are quite a few instances of that happening, many of which are listed here: https://wiki.alopex.li/BetterThanJson
Re: Fear and Loathing in YAML
#64Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.
Correction: YAML is a superset of JSON
Re: Fear and Loathing in YAML
#65Amazon's Ion format is decent, albeit not so long in the public domain, i believe
That is quite nice! http://amzn.github.io/ion-docs
Re: Fear and Loathing in YAML
#66Earlier quoted context omitted.
That's not a bad argument against using TOML, and I'm inclined to agree that TOML is more verbose than it has to be for heavily-nested maps-of-maps-of-maps. Which you can pretend is a strength, since I consider doing that an anti-pattern. But it is a valid critique. However, the TOML they offer as a comparison to the StrictYAML is probably auto-generated (they do say "serialized TOML equivalent") and it's quite a bit…
> TOML deliberately has a couple of ways of writing arrays, and a one-line short format for maps: you're supposed to alternate these, and this technique could eliminate most of the repetition in that particular file. Could you provide an example of what you mean, or point to some such? We're having a spot of trouble with arrays of maps ourselves.
If you look at https://github.com/toml-lang/toml/blob/master/toml.md, you'll see "Array", "Inline Table", and "Array of Tables", and you can put an inline table inside an array.
This breaks down when things get really branchy. TOML really expects keys to be symbols rather than strings.
Re: Fear and Loathing in YAML
#67We were editing a 2000 node Ant Config file by hand when the drugs began to take hold. I remember saying something like "I feel a bit lightheaded; maybe all configuration should be done in YAML from now on..."
We can't stop here. This is .BAT country!
Re: Fear and Loathing in YAML
#68Earlier quoted context omitted.
The problem is that in YAML, white space is significant. How is a formatted supposed to know: key1: value1 key2: value2 ...is supposed to be: key1: value1 key2: value2 ? How is it supposed to know if the first is actually what you meant to write? In grammars that aren’t white space dependent (such as JSON), it’s clear what this means: { "key1": "value1", "key2": "value2" }
Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.
But it hasn’t hurt Python popularity.
Re: Fear and Loathing in YAML
#69Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…
JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.
The first time I heard that, I thought it was insane. I think it's still pretty insane.
Re: Fear and Loathing in YAML
#70In a world where there's only a few primitive types no one can share uuids or dates across the wire without both sides knowing which fields are dates or uuids ahead of time JSON is too simple we need more primitive types and an extensible data notation to formalise data sharing of unknown types
That's one way to go, but there are other options. You want inline annotation of types. On the other side you can have an external jsonschema which provides the same information.
Realistically, you can't do "data sharing of unknown types" - at that point you're just sharing binary blobs.