5 ms·

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fas

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

guipsp 9y ago
Hand-edited and human-readable? With significant whitespace and tab-space difference?
- callumlocke 9y ago
  Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.
  - guipsp 9y ago
    You cannot indent yaml with spaces instead of tabs. This has been a source of confusion for years for many bukkit end-users.
NateDad 9y ago
Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space): foo: 80:80 bar: 22:22 baz: 22.22 What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342. I rest my case about both readability and writability.
- thanksgiving 9y ago
  > bar: 22:22 I know zero toml (don't even know what toml stands for) but I'm pretty sure you meant the value of bar is the string 22:22 based on foo.
  - falcolas 9y ago
    I think he's attempting to point out a shortcoming of yaml; I can reproduce it myself in Python. That said, I've never run up against this myself - in the face of potential ambiguity I attempt to be explicit, and surround it in quotes to be explicit string. TOML itself is going through its own growth pains brought on by a rather sizable spec. For example: >>> pytoml.loads("foo = 20:20:20") [...] pytoml.core.TomlError: <string>(1, 9): msg
- callumlocke 9y ago
  I agree that's a downside, but it almost never comes up in practice, and it's solved by syntax highlighting when it does. I'm always in a code editor when editing YAML, it's not something that goes down the wire and needs to be debugged without syntax colours. For config files it's fine. Maybe TOML is even better, I haven't used it. I'm just saying these problems raised about YAML have never really affected me and I use it all the time. For config only. JSON for data exchange.
donatj 9y ago
If it's something you do thousand of times a second, like say a php app parsing a config it makes a HUGE difference. A number of PHP framework that use YAML config files actually cache the results in memcache because a network request is faster than parsing YAML from local disk.
- falcolas 9y ago
  If it's something you do thousands of times a second, then opening, reading, and parsing a config file is absolutely something you should be caching, no matter the implementation.

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

guipsp 9y ago

Hand-edited and human-readable? With significant whitespace and tab-space difference?

callumlocke 9y ago
Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.
- guipsp 9y ago
  You cannot indent yaml with spaces instead of tabs. This has been a source of confusion for years for many bukkit end-users.

NateDad 9y ago

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space): foo: 80:80 bar: 22:22 baz: 22.22 What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342. I rest my case about both readability and writability.

thanksgiving 9y ago
> bar: 22:22 I know zero toml (don't even know what toml stands for) but I'm pretty sure you meant the value of bar is the string 22:22 based on foo.
- falcolas 9y ago
  I think he's attempting to point out a shortcoming of yaml; I can reproduce it myself in Python. That said, I've never run up against this myself - in the face of potential ambiguity I attempt to be explicit, and surround it in quotes to be explicit string. TOML itself is going through its own growth pains brought on by a rather sizable spec. For example: >>> pytoml.loads("foo = 20:20:20") [...] pytoml.core.TomlError: <string>(1, 9): msg
callumlocke 9y ago
I agree that's a downside, but it almost never comes up in practice, and it's solved by syntax highlighting when it does. I'm always in a code editor when editing YAML, it's not something that goes down the wire and needs to be debugged without syntax colours. For config files it's fine. Maybe TOML is even better, I haven't used it. I'm just saying these problems raised about YAML have never really affected me and I use it all the time. For config only. JSON for data exchange.

donatj 9y ago

If it's something you do thousand of times a second, like say a php app parsing a config it makes a HUGE difference. A number of PHP framework that use YAML config files actually cache the results in memcache because a network request is faster than parsing YAML from local disk.

falcolas 9y ago
If it's something you do thousands of times a second, then opening, reading, and parsing a config file is absolutely something you should be caching, no matter the implementation.