Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^3: An Idiot's Guide to YAML

by perrin (Chancellor)
on Jun 08, 2007 at 21:18 UTC ( [id://620101]=note: print w/replies, xml ) Need Help??


in reply to Re^2: An Idiot's Guide to YAML
in thread An Idiot's Guide to YAML

Oh, don't get me wrong. Your post is very welcome, and we're glad to have you here. I was mostly interested in what your motivation was because I personally find YAML kind of pointless. It looks a lot harder to work with than most of the other config choices to me. Nevertheless, it seems to be very popular in certain camps.

Replies are listed 'Best First'.
Re^4: An Idiot's Guide to YAML
by clinton (Priest) on Jun 09, 2007 at 12:21 UTC
    I don't understand the problems that people have with YAML. I have thousands of lines of YAML config files, all produced by hand, and the only problem I ever had was using an editor that added a tab rather than four spaces.

    The whitespace for me is a bonus, rather than a limitation - it makes it easy to read and thus easy to scan through.

    For XML, you really need an XML editor - it is good for portability because it is well supported, but for maintaining config data by hand, for me, nothing beats YAML

    clint

      Well, my original question was why you prefer a YAML config over a perl one, or something simpler like an INI file.
        Sorry :)

        YAML is more concise than perl, and more powerful than INI.

        I realise that people are more comfortable with the poison they know, but I picked up YAML quickly, and fell in love with it quickly. For me, it just makes sense. I assumed it would be the same for others, so I'm always surprised when people don't see it the same way.

        Clint

        INI is great until you need to store anything with more than minimal structure. Lists and tables can be hacked in, but are not really supported.

        I've had to write code like this:

        my $param = get_ini_param('Foo','Bar'); my @param1_params = split /,/, $param; # repeat for 37 different parameters with different parsing requiremen +ts, slightly different structure.
        too many times. In the end I wind up rolling my own text serialization library just to use INI format.

        YAML solves this problem very nicely and, IME, it is easy to edit by hand.


        TGI says moo

Re^4: An Idiot's Guide to YAML
by Anonymous Monk on Jun 08, 2007 at 23:12 UTC
    Because it beats XML :)
      If it does, so what?

      Colon-delimited files are great for strictly table-natured data. CSV is great for slightly more complex table-natured data.

      Windows-style INI files are widely supported and can handle grouping. Unfortunately, many things which look a little like them are found in the wild.

      XML is verbose, but it's standard, well-supported, and can represent arbitrarily complex relationships. Perl hashes are, within Perl programs, exactly as flexible on all three counts. They do come up a bit short if one decides to port a Perl program to another language, as either the config format changes or you end up having to parse Perl hashes in another language. Parsing Perl's hash syntax shouldn't be that difficult, but chances are the other language already has an XML library or seven.

      YAML seems to be an interesting solution to not much of a problem. I applaud you for wanting to learn it because it's interesting. That's enough reason to learn something. As for useful purpose, the legibility does seem nice from the examples I've seen. A lay person might be taught how to write it without being much intimidated. However, I think the standard for dealing with lay people these days is a pretty configuration wizard. So that, I think, limits the truest audience for YAML as a configuration tool to non-programming sysadmins.

        The frontier between what is a data and a configuration format seems sometime quite blurry.

        INI are nice except when you have really nested information structure. They probably should only be used as configuration file, not as data store or worse read-write configuration files with some program state ad/or piece if code stored inside (I have seen both). If only because I may want to store configuration files on read-only media. And as previously highlighted by mr_mischief the INI format knows some various subtly incompatible variations.

        XML is so well known for its abuses that there is no need to list them. But supported nearly everywhere it is a good language for serialization and multiplatform exchange. A use of XML that makes me seriously sick is XML as configuration file. For anything beyond simple parameters XML files are simply too verbose and have such a low ration informatio/noise that they become nightmarish (ex: most Java application servers hell). Please say no to XML configs !

        YAML fits well between those too : as a light serialization language or for complex configurations, it is quite simple to parse (simpler than XML at least) and can represent complex structures very lisibly.

        Using Perl code as configuration has the problem of executable code in config file which can induce tricky security problem and is at least more complicated to securize system (executable code on noexec partitions ?). Perl as data format, well … do you want to execute code coming from an external program in yours ?

        Anyway thanks to superdoc for his helpful post (I did exact the same misreading …).

      Does it? For what? Both seem pretty clunky for config files, and XML is probably better for data exchange between different languages since it's better supported.

        XML is probably better for data exchange between different languages since it's better supported.

        That's a point in favor of XML, but the argument against it is that it tends to be bloated and hard to read and edit manually. YAML is a little eaisier to mess with in a text editor (I know someone who's totally addicted to it, he does things like type up his "TODO" lists in YAML, so he can write little perl scripts to sort them, etc.)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://620101]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (3)
As of 2024-03-19 07:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found