Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Why is Perl so bad with XML?

by ajt (Prior)
on Jan 29, 2002 at 16:29 UTC ( #142318=perlmeditation: print w/replies, xml ) Need Help??

In this node "XSLT vs Templating?", Masem asks about using Templating or XSLT. I read the node carefully as I'm doing a lot of web work at the moment, that is very heavy XML based, as a quick look at my recent postings will verify.

I chose this very provocotive title as I believe that Perl, and possibly open source technologies in general are not percieved as XML frieldly, as Java or even MS!

A quick look at any publisher: ORA; Wrox or Manning, will quickly show a large number of Java/XML, Java/XSLT books, and even Python/XML, but nothing Perl/XML. Why?

The Java "junkies" believe that XML belongs to them, it's almost a given, and the books, and web sites ( and only strengthen this image.

When people compare XML technologies, Perl normally doesn't even get a mention, it's normally this Java Parser versus that one, and then there's MSXML, but that's it. Everyone in the XML industry has heard of Cocoon, how many people know AxKit?

I've been playing with Perl/XML for a year or so now, and have found that there are the tools out there to get things done.

There is now a selection of parsers, and a selection of tools built on them. We have W3C standard interfaces: DOM, XPath, and Perl style interfaces: Twig, Simple. XML::LibXML is even very fast???

Why do people say "Java/XML" and not "Perl/XML"? What is wrong with us?

Replies are listed 'Best First'.
Re: Why is Perl so bad with XML?
by Matts (Deacon) on Jan 31, 2002 at 07:57 UTC
    I hate seeing questions like this, as it perpetuates a myth, like Mirod's lightning talk. Perl is not bad with XML. It really rocks at it. It has some of the most powerful tools for handling XML in the entire industry (check out SAX::Machines if you don't believe me), and has some of the leading minds on the subject who use Perl for XML munging all the time (Tim Bray for one). So if you're looking for a problem with Perl and XML you'll only find one: you.

    Thats right, because the general perl hacker's attitude about XML sucks. They see it as overhyped (which it is) and unweildy (which it can be) and hard to learn all the different acronyms (which is true too). But the hype and the unweildyness and the acronym fear that Perl hackers see simply gives way to the Java hackers, who aren't afraid of this stuff.

    I hear people complaining about CPAN's XML module situation for example: "How do I decide what to use?". Yet they didn't consider going right to the source of the matter: Now on the only regular monthly technical column is on guess what? That's right, Perl and XML. Kip even did a whole series of articles untangling the mass of modules on CPAN. Now try Java. Where do you go for a package that will let you work on a stream in a tree-like way (a-la Twig)? They have no CPAN, you have to go hunting, or be "in the know".

    So I'll turn it around... Why do the Perl XML hackers need so little information (books, tutorials, etc) about Perl and XML? Well because it's so damned simple that's why! Want to parse some XML into a structure? "XMLin()". Want a fast DOM with XPath support? "XML::LibXML". Want SAX parsing? "XML::SAX". The answers are easy for perl hackers, and so we just get our jobs done.

    But make no mistake - perl is a lot less popular than Java is these days. AxKit vs Cocoon is the perfect case in point. Our -devel list has 70 people on. Cocoon's has over 500, and a lot of the people working on Cocoon are from commercial companies like HP and Sun (HP just submitted a massive patch to enable some funky SOAP stuff, for example). So your question really says a lot more about Perl than it does about Perl and XML. You could ask the very same question about "Perl and Databases" (e.g. there are lots of books on ODBC, JDBC and ADO, but only one on the Perl DBI). Or about "Perl and I/O" (yes, there really is a whole book dedicated to I/O in Java, maybe more than one).

    Go back to work. Nothing to worry about here. Unless you mean about Perl's overall popularity, in which case sure you can worry. But we'll never be a Java or a C#, we just don't have the marketing muscle.

      ...the general perl hacker's attitude about XML sucks.

      Given how provocatively you state that, let me state my attitude and you can explain how my attitude sucks.

      My attitude is that XML solves problems I don't have, doesn't solve problems I do have, and introduces new problems I didn't have. Therefore I don't use it.

      First, how does it solve problems I don't have? Well I work with a lot of data which by nature is tabular. I don't need arbitrary nested data formats, and I don't roll my own format every 5 minutes. When I need to manipulate data it is in a relational database, when I need to exchange it, CSV is a self-documenting format which solves my needs, has been standard since before XML existed.

      How doesn't it solve problems I do have?

      • Throwing around buzzwords won't help when I have to handle data from someone who thinks that "prepaid in full" should be a new delinquency code when there is a perfectly good field present for the prepayment code.
      • Saying that we will all agree on the name of something doesn't help when you have a linear process where the same dollars are called respectively interest, coupon, and wac. Said names having been established for centuries, they aren't going away because I hate working out the data mapping.
      • Nothing will really help when companies like Microsoft decide that if http is considered safe by firewalls while new transportation protocols are not, then the right solution is to tunnel your data in a protocol built on http. All that SOAP is going to mean in the end is that firewalls will need to deconstruct the http protocol to distinguish safe from unsafe traffic and filter anyways. (A decision they will come to after people inevitably get burned.)
      How does it create problems I didn't have?
      • While it is a great dream that only valid XML tools will be certified, it is painful to use a valid tool and have to be the one to tell people that their handrolled tools to produce XML don't work. (Speaking of which is the "XML feed" that PerlMonks produces valid? It wasn't when I last checked, which was a while ago.)
      • Of course there is a lot of truth to all of your comments about XML being overhyped, unwieldly, and too loaded with (almost) meaningless buzzwords.

      Unless I am mistaken, this is roughly the attitude that you think sucks. You think that it sucks that I don't want to use XML. You think that I should use XML because the rest of the world is going to use it. You think that it is my duty to make XML popular in Perl.

      If so, then it is your attitude that sucks. If I look at a tool and see that there are a lot of costs and no real benefits for what I need to do, then I won't use it. The fact that everyone + dog is going to use a tool has no real weight with me - if I thought that way then I would use Windows, Java, and would be considering migrating to .NET. In short I believe that my attitude is good!

      I maintain that it is attitudes like mine that helped my employer make a profit last year with strong sales of ongoing contracts. Even if we weren't continuing to sign up customers this year, we would make a profit just on ongoing revenue from existing contracts. Saying that I should become less productive as an advertisement for Perl's capabilities strikes me as very odd logic. My direct experience is that being productive with Perl has lead to lots of people around me having to learn it. And that means thinking about the costs and benefits of tools, and only using ones whose benefits exceed the costs.

      If you want to convince Perl hackers people to use XML, telling us that our attitude sucks is the wrong approach. Don't say that there are lots of complex stuff in the XML world that Perl is good at. There is no point in saying that world + dog uses XML. As the phrase goes, managing open source developers is like herding cats. You need to convince the cats that from their point of view it is good to do what you want. For instance you can demonstrate that XML is fun. Or show how XML helps us easily solve our real problems.

      PS I don't want Perl to be a Java or a C#. They aren't fun to work with, and if Perl tries to become them then I will go off and find something more interesting to do with my life.

      Reorganized my complaints slightly.

        The problem I have with your attitude ("Just because everyone and his dog is using it has no weight with me") is that this continues to push Perl into history. It shows the world that hard core Perlers care not for this new fangled technology, they'd rather not think about it or learn about it. And so people go elsewhere. I'm talking about marketing of course, and most hackers don't give a hoot about marketing, but it's an issue Perl faces (why do you think the Perl 6 project exists?).

        The world changes, and we have to handle new data formats. You're lucky if you're in an all Perl shop and don't deal with outside customers or other people in your department handing you data, but most of us don't live in that world. We do live in a world of strange tabular data formats, and perl handles those just fine, but one day your customer will have to send thier data to an MS shop, and they'll ask for XML, and then they'll ask you if they can send you their XML, because that's easier for them. It's just how the world works - we can't stop it turning even if we want to.

        I've never suggested that everyone should use XML for everything just because, it's a tool, and a damn useful one - being able to describe data structures in a language independant way is a powerful paradigm. But I'm not here to persuade you to use a technology. Simply to convince you that you can use it if you want to or need to, and that perl is damn good at the job.

Re: Why is Perl so bad with XML?
by chromatic (Archbishop) on Jan 30, 2002 at 03:54 UTC
    Perl is so good at text manipulation that XML wasn't widely acknowledged as the one true data format. We're used to data munging and we're good at it.

    <zealotry class="potential"> Java was a nicer fit with XML for two reasons: 1) the DOM exemplifies the Java approach and 2) it beats the alternatives in Java. </zealotry>

Re: Why is Perl so bad with XML?
by mirod (Canon) on Jan 31, 2002 at 09:24 UTC

    Yep, as Matts I like perpetuating myth, and I often ask the question: What's Wrong With Perl and XML? (and here is the lighning talk version) ;--)

    I don't think Perl sucks though, I think it works great with XML (I should know, I use it everyday for it!). I just think there is an impedance mismatch between the 2 worlds: It all comes down to perception: Perl is perceived as a hacker tool while XML is perceived as IT territory. So XML code is written by IT teams, in Java, using IBM or Sun tools, and it takes them month to do so, because it is perceived as complex, so they can get away with it. It doesn't matter that Perl's excellent tools, written by Matt or other single-person entities, could be used to do the exact same job, just faster.

    Maybe the new, which hopefully will become will improve things by providing a single entry point for all things about Perl and XML, as at the moment it is quite hard to find the information (we really, REALLY need to update the !@#$%^&* Perl and XML FAQ, which is the first hit returned by Google and which has been obsolete for at least a couple of years now! (and yes I am guilty of not working on it too ;--( ).

Re: Why is Perl so bad with XML?
by steves (Curate) on Jan 31, 2002 at 19:01 UTC

    Java programmers outnumber Perl programmers here by about 20-to-1. I'm pretty much the lone Perl progammer and I believe that, day to day, I crank out and parse more XML than the rest combined. I think that's largely because it is so easy. Although sometimes I think that hurts -- I get the impression some people think I've just hacked up some regexp's when, in fact, I do almost all of it with Perl XML packages from CPAN.

    On the other side, it took the Java guys about a year to get away from custom Java string parsing code (yuck) and start using some real XML tools. So go figure ...

    As to the argument for/against XML itself, the answer is simple: It's here, so you will have to deal with it if it comes your way. I do find, however, that many people complicate simple data import/export models that are single row oriented (e.g., better suited for delimited or CSV formats) by coming up with utterly silly XML DTD's that just blow the whole thing up into 10 times more work. On the other side of that, I deal with a half dozen or so interfaces where XML is a perfect fit for the complex, hiearchical nature of the data.

    I always try to do what makes sense and what's easiest. I think out of our three friend Laziness, Impatience, and Hubris I may have an extra dose of Laziness ...

Re: Why is Perl so bad with XML?
by redsquirrel (Hermit) on Jan 31, 2002 at 15:32 UTC
    ++ to both Matts and mirod, great posts.

    I just read Programming Web Services with XML-RPC, and I thought it gave a lot of exposure to Perl. One of the authors is fellow Perl hacker, Joe Johnston, who sprinkled Perl examples throughout the book, not just in the chapter devoted to Perl.

    I echo Matts' point that perhaps one reason a lot less books have been written about Perl and XML is because Perl makes it so simple. When I first picked up the book, I turned to the table of contents to see how long the Java chapter was compared to the Perl chapter. At first I was discouraged by the fact that the Perl chapter was the shortest of all languages covered (Java, Perl, Python, PHP, ASP), but after reading the book it was clear that the Perl chapter was so short because there's not that much to explain! The Frontier-RPC module makes XML-RPC extremely easy and straighforward with Perl, just as so many of the XML Perl modules do.


Re: Why is Perl so bad with XML?
by peschkaj (Pilgrim) on Feb 01, 2002 at 12:47 UTC
    I'm somewhat in agreement with Tilly on this one. XML creates a host of issues that I really don't need to or care to deal with. Admittedly, this comes from someone who writes perl mostly for systems administration and monitoring, but I feel that XML has a host of problems, problems that people far more eloquent and knowledgeable than I have already enumerated.

    However, I also think that perl is great for XML. Perl is fantastic for text manipulation. What is XML apart from text with a bunch of angle brackets thrown in for fun?

    In direct response to your final question, I think that people don't say "Perl/XML for a few reasons. It is my firm belief that Perl programmers tend not to get swept up by the latest and greatest craze quite as easily. Publishers don't scramble to produce books titled "Perl with BUZZWORD" because most of us knew about it when it was still an RFC and either 1) picked it up then or 2) decided that we probably didn't need to know it.

    I know that last statement is a massive generalization, but I think it holds true (mostly). Other programming languages tend to pick up on buzzwords faster. Not to criticize, but Java has always seemed, to me, to be the pinnacle of this. The Java book market and documentation seems to be filled with buzzwords. At my local Borders, there are 2 7-foot tall shelves of Java books. When I look at the titles, I can trace the buzzwords from about 3 years ago to the present-day. When I look at the Perl books, I can at least find a book on what I would like to know.

    Take it for what it's worth.
Re: Why is Perl so bad with XML?
by Steve_p (Priest) on Feb 01, 2002 at 13:44 UTC
    I think this has more to do with the major software manufacturers than with the actually users of the software. Part of it has to do with the software available. Part of the blame has to go to the Perl community at large. When I say the major software manufacturers, I mean Oracle, Sun, IBM, and Microsoft. The first three have been pushing Java/XML at least three years. Microsoft is, of course, pushing the .NET/XML thing. What company is trying to sell Perl/XML?

    Also, getting Perl/XML can be a bit of a challenge for some users, especially Windows users. Due to the lack of a C compilier on 99% of all Windows machines, most Windows Perl users rely on ActiveState for the various ppm packages. While I am very happy with Perl on Windows, I do have issues with some of the package maintanence. Many of XML packages you mention are not available for Windows users who rely on PPM. Now, while I realize many of the us hardcore Perl programmers are using various flavors of Linux or *BSD, many newbies are still on Windows. If the XML packages aren't available for them, they will become Java programmers. I've even had problems get Sablotron working some UNIX platforms, so I've even had to resort to Java for some projects.

    Finally, while a lot of great work has gone into the XML packages, it may be that the writers in the Perl community haven't thought of Perl/XML as a good topic for a book. I can't believe that O'Reilly wouldn't publish a Perl/XML book. Possibly, their waiting for the right author (or any author) to step forward. Maybe someone here could write it.
      This one's easy to answer...

      For ppm, try this:

      C:\> ppm ppm> set repository kobes ppm> set save ppm> install XML::LibXML
      Randy Kobe's stuff rocks. He's got LibXML and LibXSLT, and XML::XPath, and AxKit and all sorts of other goodies.

      As far as books are concerned, there will be something soon, but not from me. And only for certain values of "soon".

Re: Why is Perl so bad with XML?
by cjf (Parson) on Feb 04, 2002 at 06:30 UTC
    For those who are interested, I stumbled across a Perl & XML book over at O'Reilly. It's slated to come out in April (2002), at which point I'll definately be adding it to my collection. Here's the description:

    Perl & XML is aimed at Perl programmers who need to work with XML documents and data. This book gives a complete, comprehensive tour of the landscape of Perl and XML, making sense of the myriad of modules, terminology, and techniques. The last two chapters of Perl and XML give complete examples of XML applications, pulling together all the tools at your disposal.


AxKit now Apache Axkit
by ignatz (Vicar) on Feb 02, 2002 at 18:06 UTC
    Just noticed this at
    AxKit has recently become an official Apache project under the XML projects umbrella. Please bear with us while we make the transition over to and move our mailing lists over there.
    I think that this will make a big difference in some kind of wierd, open-source branding kind of way. Now Fortified with Apache Goodness!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://142318]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2023-02-09 02:35 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (44 votes). Check out past polls.