Hacker News Reader

Comment by callumlocke | Hacker News Reader

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.

View on HN

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.

> 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.

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

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.

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.

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.

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

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.

You cannot indent yaml with spaces instead of tabs. This has been a source of confusion for years for many bukkit end-users.

Reply on news.ycombinator.com