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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday August 05, 2003
12:55 AM

When is Simple Not Simple?

[ #13913 ]

I like when CPAN modules have simple interfaces. I like to use shell aliases and will never give up the command line. I like things that make my life easier.

If you want to make my life easier, do not make tools that require me to write XML to use them!

To help you remember this rule, I have written a simple song:

when you find yourself hacking
a tool you've been lacking
you have one great choice to make

make it painless to write
skimp docs, tests, and the like
"to use it, just read the source code!"

or make it easy to use
make a good API
and remember the best rule of all

XML, XML, XML
it's not for configuration files!
XML, XML, XML
hard to write! hard to read! angle braces!

"easy for me!" may be hard for your users
so they'll curse your name in their frustration
and wish for something like YAML

so work a little harder
and write a smarter parser
and everyone will think you're swell

The moral of the story is, "Don't annoy a music major."

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.
  • No it's not! (Score:5, Interesting)

    by mir (51) <xmltwig@gmail.com> on 2003.08.05 2:46 (#22769) Homepage Journal

    What do you mean XML is not for configuration files? See how elegant the XML version [xmltwig.com] is compared to the YAML version [xmltwig.com]?

    The problem is that it is really hard to go from one to the other:

    perl -MXML::Simple -MYAML -e'print Dump (XMLin( $ARGV[0]))' config.xml > config.yaml

    (modulo forcearray [cpan.org] and other option problems of course)

    ;--)

    --
    mirod
  • by hfb (74) on 2003.08.05 2:51 (#22770) Homepage Journal

    and write "CPAN: The fucking musical rant!", a musical spanning several hours and a finale of encrypted music though everyone in the audience would have the words....XML is the least of it :)

  • "Hard to read" (Score:4, Insightful)

    by Matts (1087) on 2003.08.05 6:38 (#22775) Journal
    Depends what you mean.

    XML is easy for a computer to read. And it's easy for a programmer to write an interface to.

    That's perhaps where the problem you perceive lies - it's almost too easy to punt and opt for XML rather than some custom config file.

    YAML kind of gets rid of that problem, but it brings along a bunch of other problems, such as lack of tools for languages other than Perl (especially C and Java), so we end up isolating ourselves from other programming communities. Yes, the YAML spec is open and anyone can implement a parser. But the Java and C parsers are still works in progress, and don't allow as easy access to the data as the XML libraries for those languages.

    Perl hackers complain far too much about XML. It's ironic really, given how hard to type perl code is (all those sigils). I don't dislike YAML. I just don't think it's the panacea that perl hackers have been convinced it is. And now I see even the perl core is opting for this non-standard data format (that we'll likely include a YAML parser in the perl core before we include an XML parser is just the dumbest thing ever).

    People who write apps that store their configs in XML should not be criticised - they're doing exactly what we want them to do - make their config files process-able by standard tools. That's no bad thing, and you shouldn't complain about it IMHO.
    • And now I see even the perl core is opting for this non-standard data format -- no, PAUSE is opting for it.

      we'll likely include a YAML parser in the perl core before we include an XML parser -- I don't think so. But consider that there's only one YAML parser, and multiple XML parsers : selecting one of them would probably produce endless wars.

      • We in the Perl XML community already solved the "multiple XML parsers" war problem when it was last raised by the perl community. It's a dead argument now. Just install XML::SAX and be done with it.
    • XML is easy for a computer to read. And it's easy for a programmer to write an interface to.

      If I recall correctly, XML was designed so that hyoo-mons could read it. The "computer", that is to say programmers, can munch any digital data format you choose. XML is still a bear to deal with. Subclassing parsers or writing callbacks for event-driven parsing is not particularly straight-forward for many programmers. This is not to suggest that I pine for the days of random ASCII formats (like YAML), but I

      • I hear you on the event driven parsing front.

        I'm writing a pull parsing module for XML right now that gives you nodes that are the same as SAX2 nodes. Ultimately a pull parser is probably a better low level parser as it's easier to write an event driven parser on top of a pull parser than it is to do it the other way around.

        But all of this reminds me of Mirod's call to not use low level APIs to read XML. If you want to just access bits of an XML document there's an awesome syntax available to do that: XPa
    • People who write apps that store their configs in XML should not be criticised - they're doing exactly what we want them to do - make their config files process-able by standard tools. That's no bad thing, and you shouldn't complain about it IMHO.

      Expecting users to write configuration files in XML is wrong. Maybe, someday, when usable XML authoring tools are widely distributed, the situation will change. I do point out that user-hostile file formats such as that of sendmail.cf also needs a slightly-ni

      • Well, to be honest you don't have to write the XML by hand. Just create the data structure you want any way you want (through a dedicated GUI for example) and let XML::Simple dump it as XML. This also works for YAML, BTW.

        --
        mirod
      • Expecting users to write configuration files in XML is wrong.

        Actually, I think your expectations here are wrong. Or at least your POV.

        One of the benefits to XML is its anglebrackety syntax. Bemoan it all you want, but by the time XML came around, the world had lovingly embraced HTML. For all of its warts, give someone a copy of Notepad.exe and they can start writing HTML. And XML. And perl.

        What I think you're harping about is the data/document duality. XML as originally envisioned is much eas

  • I find XML to be quite readable, and much more friendly and powerful than most alternatives (though I have not played with YAML). Frankly, I find it amusing to see someone complaining about XML readability in a Perl forum. ;)

    What really bothers me is learning another format, and installing another parser, for a grammar that turns out to have severe limitations, and eventually has to be changed or replaced.

    Take Mozilla's search plugin syntax for example: a clone (apparently) of the syntax used by Apple

    • Yep, that's the best solution. As long as it's possible to configure the program without writing or editing a difficult file format, I'm reasonably happy.