All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

JSON is much simpler, but to be fair it only supports a subset of what YAML does. For example it's not good for serialization, because you don't have any way to specify type names.

Anyway, JSON being much simpler is why I wrote a JSON parser and generator for Perl 6 (with some help from Johan Viklund), see http://github.com/moritz/json/ [github.com]. As far as I can tell it implements JSON to 100%.

Somehow I don’t think that trying to be a serialisation format – for several languages with significant differences – and human-readable and -writeable, all at the same time, is an argument in favour of a format.

I had this argument with Ingy way back when he was coming up with YAML. He made it over complex (IMHO), resulting in a spec which made XML easier to implement than YAML (32 pages of spec vs nearly 200), which makes no sense since YAML was supposed to be EASIER to read and write than XML.

It's a bit more human readable than XML, but not much, and edge cases like this are going to make it a LOT harder to debug an issue with YAML than with XML.

I'll be you'll break a lot of code with this. I've previously worked with a module (can't recall, but I think it was SOAP related) which was guessing my data types and silently converting things for me. No end of headaches:(

I didn't report this to you because I assumed you had deliberately kept things simple:)

The boolean documentation you link to is from the 1.1 spec. Its a bit insane to have that many special values. 1.2 took a lawn mower to it [yaml.org] and now there's just two bool values, "true" and "false".