Clear questions and runnable code
get the best and fastest answer
Re (tilly) 4: Why is Perl so bad with XML?by tilly (Archbishop)
|on Jan 31, 2002 at 20:43 UTC||Need Help??|
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...