New breath for YAML in Perl

ferreira on 2005-12-26T00:20:36

This Christmas had seen the release of two YAML-related modules which are bound to advance YAML support in Perl. First, Audrey Tang released YAML::Syck 0.01. And then YAML reached 0.49_70. Indeed, both (if I understood correctly) were inspired by the recent joint work of Ingy döt Net and Audrey, which took shape as code. They are the ones who should be doing such an announcement, but I am so eager to see complete/bug-free support for YAML that I could not resist to broadcast my salutation to these two outstanding Perl developers.


Re:

Aristotle on 2005-12-26T14:30:58

Is there anything YAML does which is not better done using one of XML, JSON, Data::Dumper, or Storable?

Re:

Alias on 2005-12-26T14:44:38

When used for JSON-subset problems, YAML is far more readable for ordinary humans... Secretary-level readable even.

So YAML can be very very useful for config files (when .ini isn't enough any more) and spitting out reports.

But as for the rest... I don't see anything shiny (unless there's something in the whole streaming thing I'm missing).

Re:

Aristotle on 2005-12-26T15:52:06

Yes, YAML’s syntax in the most basic form is very readable. But how writable is it at this point? It seems like YAML started out as a very cool config syntax that got out of hand due to serialiser envy, and subsequently grew a lot of syntax I have no use for in config files as well as a bunch of Perl-centric features that alienate other dynamic language communities. At the same time it does a bad job at non-trivial serialisation.

It’s a pity, because I was shopping around for “wiki markup for config files,” and YAML prior to its delusions of serialisation looks like it would have fit the bill perfectly. Sigh. JSON is a lot less pretty, but the syntax rules fit in a single paragraph and it’s cross-language. (Note that I picked up on it much before it had any hype momentum.)

I guess you can still use YAML as a zero-effort report generator or a debugging aid… that’s about all I find it’s good for anymore, though.

YAML x XML, JSON, Data::Dumper, Storable

ferreira on 2005-12-26T15:20:51

Well,
  • XML is (1) sometimes too verbose, (2) has an underlying model node(name, attributes, children) which doesn't map directly to Perl, (3) (on the pro side) has a very simple core and (4) is massively popular nowadays
  • JSON is (1) YAML with only inline collections - easily unreadable and (2) looks like Lisp (but with braces and square brackets). (3) Also very simple. (4) On vogue due to AJAX hype
  • Data::Dumper spits Perl - (1) Perl is good, but not necessarily easy, (2) not simple at all, but powerful
  • Storable is binary-encoded - not human-readable

YAML (1) maps very naturally to Perl, (2) is closer enough to Perl without scaring other communities, (3) is a little huge like Perl to provide power, (4) was meant to be cool :)

YAML is just another option - no argument would make it prevail over any other. Each has its niche. In some contexts, some tools (including serialization languages) are more natural than others: like JSON in JavaScript/AJAX applications (because JSON is a JavaScript set) or Ant for building Java applications (just natural for the corresponding development needs).

Re:

Aristotle on 2005-12-26T15:44:00

No no no. I mean, name any particular task, then tell me why YAML does this particular task better than any of the other choices. Just listing upsides and downsides of each particular choice is pointless.

As I conceded in the other post, as a debugging aid and for report generation, it’s good. But what else?

YAML is better?

ferreira on 2005-12-26T17:34:05

"Tell me why YAML does this particular task better than any of the other choices." How can I say such a thing? I can tell you that I already used YAML in pretty complex configuration files, with lots of metadata, and that was handy to write YAML rather than fussing around with the program source. But so I did with XML as well. And I have had the chance also to save YAML into databases as a portable way to load/dump structured data in plain strings/clobs stored in relational tables. But I don't claim it was the best choice - it was something that worked.

What YAML does better is what it does least

n1vux on 2005-12-26T23:12:58

The original poster had a key point -- YAML is simple and safe. (I won't wade into whether it's as simple as it used to be or simple enough.)

YAML does NOT use EVAL, so it's safe for cases where you don't want to trust the persons who might tweak the file.

YAML does not pretend to be readable Lisp, and thus doesn't drag in XML::Parser or other XS modules. If I want matching brackets, I'll use real lisp, thank you very much. (The latest announcement says you CAN have an XS module if you need speed, but why would a config file grow so big you need that?!)

Although if the Config file needs more structure than an INI file has, maybe it should be an real DB anyway ...