Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • How does YAML compare to XML in terms of heaviness, then? I thought YAML was supposed to be a lightweight configuration language. If not, then I really don't see why people wouldn't just use XML or .ini-style config files.
    • If I can use the machine-readable vs geek-readable vs human-readable differentation, then I can sum up the difference as the following.

      Binary file formats are machine-readable, but NOT geek-readable or human-readable.

      This makes them small and compact, but very hard for developers to handle and work with, because it requires you be highly intimate to do anything at all.

      XML is machine-readable AND geek-readable, but not human-readable. The format is designed for machines, but are done in a human-enough way that it's easy for developers to understand them, and work with them, without needing to be entirely intimate with the format.

      This STILL makes XML not human-readable, so in general people shouldn't be expected to ever have to read them or edit them by hand in the normal course of their work, they should work with XML files through a program, or view them via some other presentation medium.

      Interestingly, this means the specification for XML itself (for machine usage) is relatively compact still, but can still be fairly heavy-weight compared to a trivially simple human-readable format like Windows .ini files.

      YAML is intended to be machine-readable, and geek-readable, AND human-readable, AND still have all the features that XML does.

      This means that from a human point of view, it's fairly easy to say

          ---
          - foo
          - bar

      The downside of this approach is that the complexity FOR MACHINES is much MUCH higher. The specification is enormous in order to deal with the added flexibility and easy-of-use needed to make it more human.

      This results in a format that LOOKS "lighter" to humans, but is actually "heavier" for machines.

      As a result, XML makes a good choice for some sorts of files. If humans will not be looking at the files directly, and you need more features than you can get from a trivial format like Windows .ini, then XML is a great choice.

      In particular, XML with the use of Schemas is absolutely ideal for its original purpose of inter-system document transfer. If you need your data to cross a trust-boundary, to consume data from some other untrusted entity, and so on, then XML is the perfect choice.

      But it's not something you should tell humans to edit, and so XML is a bad choice for configuration files humans will touch.

      YAML is very heavy for machines, but it is human readable, and so it is currently quite possibly the best choice for more-complex configuration files that humans will need to edit directly.