Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: Why is Perl so bad with XML?

by Matts (Deacon)
on Jan 31, 2002 at 07:57 UTC ( #142385=note: print w/replies, xml ) Need Help??

in reply to Why is Perl so bad with XML?

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.

Replies are listed 'Best First'.
Re (tilly) 2: Why is Perl so bad with XML?
by tilly (Archbishop) on Jan 31, 2002 at 17:06 UTC
    ...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.

        Hey, hey, calm down everybody!

        I do agree that the attitude of the XML community and of the Perl community are really different, to the point of being antagonistic, as proven by the 2 posts above. The Perl way is "whatever works is fine", convenience tends to be valued above completeness and formalism. The XML way is nearly the opposite: one-format fits all, forcing "the right way" unto unsuspecting coders (Unicode isa perfect example, it annoys 99% of people to no end while just slightly improving the condition of the last 1%), elaborate all-encompassing constructs (W3C Schemas).

        Plus of course XML is verbose, and monsters like XSLT and W3C schemas are way worse, while Perl favors economy of strokes and conciseness as a way to get elegance and maintenability. At least you could do SGML golf!

        I might be wrong, of course no one has any figure about module usage, but I believe the people who write Perl modules "the XML way", like Matt, Robin Berjon, Ilya Sterin etc... are in a way off-target. In a word they look a bit like XML nationals lost in a foreign Perl country (not that Perl people look terribly good when we go out and attend XML conferences, believe me! I tend to get laughed at when I describe XML::Twig to Real XML Gurus ;--). The modules they write are not what the Perl community wants. Not that their work has no value, I think it is really important for Perl to be used in other context and to spread past its current niche, but it might be something to think about when we try to understand why some very nice modules don't seem to be used much. In any case there is a reason why the current crowd of Perl hackers loves XML::Simple and refuses to use XML::SAX::PurePerl. Java drones want SAX, Perl hackers want XML::Simple (and don't get me wrong, I would be the first to say that I don't think XML::Simple is a generic XML tool, but it is darn convenient!).

        I know that XML is annoying as it oftens bring no improvement over home-brewed formats. It is usually imposed by management in order to be buzzword compliant, but for Perl hackers it brings very little to the table, except an additional risk. But let's face it, we will all have to deal with it. XML is a bastard, verbose and actually quite tricky, format that's being used not because it is the best one for any particular purpose but because it is a standard, which allows Java projects to re-use standard SUN or IBM libraries where Perl hackers would use a CPAN module or 2 lines of custom code.

        That said I see a couple of reasons why Perl hackers would want to use XML: first as a data format it is actually quite powerful. It makes it easy to stick HTML inside data, it makes it easy to mark data within HTML text. It makes it possible to change the structure of the data without upgrading the code right away (I guess that would be between "loosely coupled systems"), really, you should try it ;--)

        Have you noticed that you are trying to convince me of something I am clearly already convinced of, and then expecting me to do something unrelated?

        Here is what you are trying to convince me of. 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.

        But I never disagreed with that. In fact I already am convinced that I can use XML. Furthermore I know I can use Perl for that. Remember my opinion that, XML solves problems I don't have, doesn't solve problems I do have, and creates problems I didn't have? Do you think I had that opinion in a vacuum?

        Of course not! I and some co-workers did several small XML projects. We asked whether this tool was useful for us. And our conclusion was that it wasn't right now, so we didn't push it farther. This is the opposite of your unfounded insult that I would rather not think about it or learn about it.

        You may not like my conclusions, but that is no reason to insult me.

        Now the only point that you offered that would possibly matter to me is what would happen if I ran across a customer who only will accept XML. My attitude is that I will burn that bridge when I come to it. As it stands, said customer would be shooting themselves in the foot since they would be refusing to exchange files in the standard formats for the industry they are in. But even so, when we need to we can produce XML. I know that because we did some trial products and had no problem doing so.

        In the mean time I will worry about the real customers I do have, and not the hypothetical ones I don't. History shows that businesses that pay more attention to hypothetical customers than existing ones tend to go out of business, and I would rather not face that. (As I write this a sales guy just cheered over a verbal commitment for another long-term contract.)

        Which leads back to the fact that what you apparently want out of me is very different than what you claim to want to convince me of. You claimed I should believe that Perl is fine for XML. What it seems you really want is for me to drink the XML kool-aide then go out, use it and tell the world that Perl is great for XML. You aren't addressing the fact that I see costs and little to no benefit in doing so. You give me no reason I agree with to do so. But you want me to do it.

        You are claiming that it is important from a marketing point of view for Perl to push XML because XML is a defacto standard. There is a difference of belief here. My belief, based on actual customers, is that you don't need to market yourself as XML everything to get business. My further belief is that being productive, and my assisting others to be productive, is a more effective way to market Perl in the long run. (It certainly has been a more effective way to market it in the short run for me.) My final belief is that working in a swamp of buzzword soup is generally painful and no fun. Even if you convinced me that it was absolutely essential to The Future Of Perl for me to do so (which you have not), then you would have only convinced me that I want to find something other than Perl to do in the long run.

        In short, I understand perfectly well that you can do XML in Perl. I don't think it is worthwhile to do it, and won't spent any energy beyond basic exploration until I am convinced otherwise.

        Now if you will excuse me, I have some useful work to do with a tool (relational databases) that we have found productive, so that next week our sales people will have another reason to call prospective clients and make more sales...

        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'm not in the industry myself, so I have no own experience with this. But your statement has a touch of self-fulfillment. If everyone thinks everyone else uses it, everyone will start to use it.

        Or is it de facto so that the majority out there uses and requires XML?
        ugh thats the third time today I've forgoten markup..


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://142385]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (11)
As of 2018-06-20 20:16 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (117 votes). Check out past polls.