Slashdot Mirror
XML::Simple for Perl Developers
An anonymous reader writes "XML has become pervasive in the computing world and is buried more and more deeply into modern applications and operating systems. It's imperative for the Perl programmer to develop a good understanding of how to use it. In a surprisingly large number of cases, you only need one tool to integrate XML into a Perl application, XML::Simple. This article tells you where to get it, how to use it, and where to go next."
XML::LibXML is where it's at, it is a) quite a bit faster and b) has a sensible interfce rather than giving you useless empty hashrefs in the middle of a tree.
Stop intellectual property from infringing on me
No, professionals write good code, regardless of the language. There is just as much shitty Python/Ruby out there as there is Perl.
"Outside of non-professional teenage Slashdot readers who still think the shitty Perl syntax is 'kewl', who the hell cares about the language anymore?"
...
I usually don't reply to trolls, but
The answer is hundreds of thousands of people around the world who use the correct tool for a given job, rather then trying to hammer in screws with the "latest and greatest".
PS, if you're not clueless and actually are a professional software developer, you can write code in perl that is every bit as readable as . It even supports comments!
- Roach
(Who writes code in perl, as well as a number of other languages depending on the task at hand.)
fine, I'll feed the troll.
Parsing perl with wet-ware isn't always easy. Obfuscating your code in the name of optimization should be countered with good commenting. Every useful script will have to be maintained, and the grandparent post is totally correct. I work minor miracles with Perl; or, miracles to me, anyway--I couldn't have created my dissertation data without Fortran--specifically g95--and Perl.
I know there are lots of useful languages out there. Every language has its fanboys. Heck, I liked the PDP-11 macro language a lot. If people produce useful code with Perl, don't complain about it; be glad for them.
This is the most pointless article I've seen linked from slashdot in a long time (and yes, I've seen a lot of crap here). What is the point of posting a run of the mill tutorial on something that's been covered many times before?
Having spent a lot of time playing with this crap lately, can I just butt into this pointless thread and say screw XML, use YAML or JSON instead. XML is a steaming, clumsy overrated turd. I benchmarked XML::Simple against YAML::Syck - the latter encoded 2.5 times faster and parsed nine times faster than XML::Simple. The syck library is indeed aptly named.
"Leverage the power of XML" by deprecating it wherever you can for a more sensible cross platform format.
</rant>
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
As true as that may be, I have never heard of any other language be referred to as a "write only language".
Love sees no species.
Slashdot.org!!
When information is power, privacy is freedom.
It only claims to support a subset of XML, and of course it is called "Tiny", so I guess I can understand not supporting CDATA or attributes (...maybe). But for a ">" in a CDATA block to cause it to fail? It doesn't seem very useful.
I tend to use Python for most things, and consider it a general purpose language, suitable for all but performance critical tasks. I'd put Perl and Ruby in the same basket, as general languages with many libraries which just help you get things done. To me, these languages seem pretty interchangeable in this respect. In that case, the choice of which to use comes down to personal experience alone.
I'm curious as to whether you have a different opinion. Lets leave aside issues of syntax. What libraries or other features would you consider makes Perl the correct tool for a particular task? Are there particular tasks for which you use other scripting languages, in particular Python or Ruby?
... utterly useless for anything of real size. XML::Simple is a huge memory sink, because, as mentioned elsewhere, it insists on generating full hash and array representations of the source XML text. This seems to be the side effect of taking too seriously a lot of Perl advice enthusiastically handed out in the older documentation. (Put file text into a huge array! Don't close your file descriptors!) The rest of us know better.
Dog is my co-pilot.
There's a reason they're called "Cowards". Those of us who've been around a while know that there are all kinds of languages out there, and plenty of them can be used to write good code. The real problem with Perl is that Larry Wall is slowly losing his mind, adding features that nobody asked for; a good example is the new, backwards-incompatible regexps. (Don't go off that there'll be a compatibility mode; that's beside the point. The hubris needed to upend this core part of the language is pretty astonishing.) Also, he seems to be spending a lot of time with the Parrot rehosting, something else that is (perhaps) of dubious value. The changes are so orthogonal to what I do with Perl (hello, how about faster OO calls?) I have to wonder if there'll ever be a reason to switch to Perl 6. (Perhaps someone out there who knows more can comment.)
Dog is my co-pilot.
I don't know about GP, but I've got a couple hundred hosts that have PERL installed, but not Ruby or Python, and getting those others installed would require alot of work. (some technical, given the age and OS on some of them... but mostly configuration management style issues)
Since there is alot of PERL code already doing work in this environment, and PERL is on everything already... it makes sense to stick with what's there.
Well, certainly as opposed to Python, anyway. I went from perl to Python with a huge sigh of relief. I try to move a still-used perl script from perl to python once a week. Eventually I'll get them all, and I can leave the language behind. But I wrote tons of perl before I discovered Python and it is a long, long road to upgrade all that stuff. But every time I do one, I get a more maintainable, more english-like tool. Sometimes it takes me several minutes to even understand what the heck a perl script (even one of mine) is trying to do. Perl just... doesn't lead you to the most readable solutions. In fact, the better at it you get, the more obscure looking your programs get, it seems to me. That's an IMHO. :)
Anyway, if someone is looking for a scripting language today, Python is the cat's meow. Readable, sensible, extensible, flexible, well supplied with great libraries of functionality, powerful as hell, very easy to debug, not unreasonable in speed.
I've fallen off your lawn, and I can't get up.
gack!
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
One thing I user it for was representing a database in XML. Once I had the DB layout in a datastructure, it was one line to print it out. Of course, this was before I knew about DBIx::XML_RDB...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
The fact that whitespace is dogmatized by the pyhon community makes the community
itself less attractive, and the language because of it. It sends the message that
it doesn't really matter what you want, the language is perfect and your code
is crap because you are too stupid to agree with how right the community is.
Guido could _easily_ put in some sort of pragma to allow other types of blocks, it's
only a matter of arrogance that stops him- coding with whitespace is the "right" way to do it.
There's also the matter of the parser. The last time I used Python everything was a syntax error, which gave little indication what was actually wrong with a piece of
code.
So you have never used APL, eh?
...), Basic, C, C++, Fortran (66,77,90,95), Gauss, Icon, Java, maxima/macsyma, mumath, pascal, perl, prolog, python, ruby, R, VB and probably a few I forget in there. The big idea I have learned is to never force fit a tool to a problem. Select the right tool for the right problem. And go from there.
...). It is not the perfect language for everything though, there are some missing bits.
... spent 15 years developing Fortran code. May it never reach 16 years.
Perl is derided by people who quite frankly don't have a clue.
We get lots of flammage from the Java and Python programmers that seem to be unable to grasp that when they try to justify their language choices by putting down other languages, they demonstrate how clearly idiotic their choices are. They cannot come up with something better than "line noise"? My god, have they not heard of the obfuscated code contest?
One can write unreadable code in any language. Perl is not unique in this regard. Moreover, Perl itself does not admit more unreadable code than other languages. The regex engine in Perl is a language unto itself. You don't need to use it, ever. But once you do, you realize how incredibly powerful it is. And you learn how to parse it, and even more scary, emit it, in your head. What takes hundreds of lines in Java (well what doesnt) becomes single digit number of lines in Perl.
In my career, I have used APL, Assembly (x86, 8080/Z80, 6502, 6800, F8,
Perl is wonderful in that it allows for rapid application development, has a really huge library to draw from (www.cpan.org), orders of magnitude larger than competitive languages, an active developer base, an active contributer base, is portable (you can run Perl anywhere, windows, linux, mac, Cray, AIX,
Ruby is neat, though I am amused by those in the Java community running over to it, thinking it is better than Perl. It is slightly different, but the syntax is actually quite close to perl. Learning it isn't hard once you know Perl, you can go back and forth quite easily. The problem in Ruby's case is speed. This hopefully will improve over time.
Python is hard for me to use. I am reminded of BASIC on IBM PCs. Some people like it, I don't. Use it if you must.
Java has always felt to me to be a solution in search of a problem. I haven't seen things that are being done in Java that couldn't be done more quickly and efficiently in other languages. Java has developed a cult-like following. Many people drank the koolaid, committed company resources to it, and poo-pooed other, better solutions. Only to discover that each "advance" meant to deliver more performance dug people in deeper to the hole, made the systems harder and more expensive to develop. And until recently, the vast majority of people were in significant denial over the fact that java was and is just a marketing gimmick for Sun. They drank the koolaid.
Fortran
APL. You want write only? Parse this: +/x
In APL, we wrote complex calculation systems in very few lines. It was a tremendously powerful language.
In Fortran we wrote complex calculation systems in quite a few lines. Not very powerful for IO, really sucked for this.
In Perl we drive complex calculation codes written in almost any language. Insanely powerful. Expressive and concise syntax, reads well when well written. Good IO, good networking, good system hooks. Can use MVC and web tools, Jifty even comes with a pony.
In my personal experience, Simple is probably the worst implementation of an XML parser in perl. For a simple implementation, I have found Twig to be much more useful, sensible and fast.
Firstly, code written by different programmers is consistently indented. C and Java programmers could argue for a millennia about where to put the curly brace, but in the end the argument is just trivial. If everyone did it the same way code would be much more readable. Sure, the language gives you freedom to work the way you want but it does so at the expense of readability.
Another reason is that indentation easily shows that one block is the child of another. Again, this makes Python code much more readable than it otherwise would be without it.
I don't think the decision was a matter of arrogance at all. It's logical, and it makes sense. Programming is often said to be part art, part science, but trading a little bit of expression in the way you indent your code for readability (and hence maintainability) makes sense to me. It does take a bit of getting used to, sure, but it is worth the effort when you come back to the code at a later date, or try to understand someone elses.
In fact, the better at it you get, the more obscure looking your programs get
:) Still, it's my favorite language (I've only ever dug into java and c++ as alternates).
Well, I can tell you that's not true. If you're willing to believe me, I'll claim that I've become very proficient at perl in the past 9 years and my code has become much easier to read. I think those who have worked with me would agree. Some have even said so specifically. You just have to have a little self dicipline and a sense of clarity and aesthetics.
Now, if you don't have such sense, or if you just like another language, that's totally cool. Whatever works for the job. But perl is a medium (like oil or watercolor) and you can make beautiful programs with it. It just doesn't do anything to assist you in that endeavor
Cheers.
Perl is a good development language. I especially appreciate the transparency of scripting languages - if something goes wrong I can examine the source immediately. But I think you underestimate the power of Java. CPAN is good, but the resources available to a Java developer are even more extensive, thanks to the combined efforts of the major software players and the open source community. Java-specific development tools are leaps ahead of most other languages. When a serious amount of effort is required to solve an problem then it makes sense to invest time in a tool that make complex systems easier to develop and troubleshoot.
This is the same approach that is built-in to the qore language http://qore.sourceforge.net/.
It makes it really easy to manipulate data in XML format.
However, qore supports deserialization of mixed text and data and multiple out-of order elements, XML attributes (imagine parsing a docbook file for example), as well as serialization (conversion of a qore data structure to an XML string) with the same features.
The same limitations regarding streaming input and very large files affect this approach, but in all other common cases, it makes it really remarkably easy to manipulate and create data in XML format using this approach.
(Qore also supports JSON with the same approach -- serialization and deserialization between JSON strings and qore data structures...)
thanks,
David
Oh yeah, it's just the absolute end of the world. Just a total show-stopper. After all, who would want readable, maintainable, consistent-looking code in a large team? What a disaster!
The author of that article says you'll want to use the magic of perl and XML::Simple because "XSLT can't do arithmetic" and proceeds to do magical things like increase numbers by 20%.
... bizarre. Of course you can do that with XSLT! <xsl:value-of select="whatever * 1.2">
That's just
Then he formats a number -- because XSLT, of course, doesn't have a format-number() function.
Next article -- why you should commute to work in an airplane because, as everyone knows, cars can't turn corners.
There are very good reasons not to. Thus, dogma. My argument is "everyone else does it the other way, maybe being flexible would be good." Your argument is "I am right and my way is good, so there shouldn't be any other way". That's Guido's argument too.
Java is well-suited for large projects with fairly well defined requirements (and potentially complex interactions between objects/components).
If the requirements are ill defined, or the system small enough to likely be confined to a single box, or the object model relatively simple (few types, lots of instances) then perl is the first thing I think of...
Unless the object model is regular and layered, then I think ruby.
Unless there is a need for blistering IO and syscalltastic goodness with function overloading, then C++
Unless there isn't a need for too many object tricks or the STL, then C.
All of the above languages have excellent tools, environments, and libraries. I think they've all got it made in the shade.
BTW, the easiest language to develop and troubleshoot is JavaScript (ecmascript). Tools like firebug make it stupid-easy. Of course, there's no regularized non-web environment for it; I've seen small efforts to that end but they always end up not going far. It's a real shame, IMHO. Prototyping, lazy-evaluating, duck typing, easy-to-read language... what's not to love?
I don't know *kicks dirt*
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I recommend you start a yahoogroup for the discussion of Python. The same applies to YAML advocates too, of course. Exchange a few snippets of code/data.
Hopefully you'll then realise how non-portable a white-space-based convention is.
Also FatPhil on SoylentNews, id 863
... as one of more than one ways to do things. Unfortunately, every Perl program I have seen (with the merciful exception of POPFile) picks one of the other ways. TMTOWTDI, don't you know.
The problem with Perl isn't the language. OK, let me amend that: s/ (t)/just $1/. Its that the culture which surrounds the language encourages practices which are at odds with maintainability. You can't seperate Perl code from Perl coders, and Perl coders are, to a disturbing degree, prone to creating unmaintainable cruft with copious use of syntatic sugar which is actually disguised cyanide. Perl would be better off if some things which are syntactically allowable were banned forever. Here's a couple:
* copious use of default parameters (a wonderful way to introduce bugs into the program by accidentally overwriting one when inserting a new line of code between two sections of code which do not look obviously related)
* $_.=$& Code this obtuse needs to be discouraged, not encouraged. Its powerful, but totally obtuse, and programmer brain time is more important than finger time, which unfortunately Perl has decided to optimize for. (Incidentally: it appends the last regular expression match to whatever string you were operating on. I think.)
* Multiple methods of passing arguments to functions. (I have come across code which uses more than three in a single source file.) Function prototypes are like seatbelts. I know you think you're smart enough to not cause an accident. Statistically speaking, you're not. Buckle the heck up.
Help poke pirates in the eyepatch, arr.
Yeah, but once you screw up the indents in a whole file of Python source, you're not going to think that this is such a great thing. See, if you accidentally flatten out the indents of Python code, you have no clue where blocks used to begin and end. If the same thing happened in Perl, you could easily straighten things out by using the curlies as cues. (Heck, my editor will fix indents automatically for Perl.) This actually happened to me once--I accidentally sucked out all the leading spaces of every line of a Python program. The resulting mess made me re-think my infatuation with the language.
Having tried Python and having used Perl for years, I can't think of any reason why we need Python. Seems to me that anything you can do in Python you can also do in Perl. The reverse may be true, but ask yourself...does the world really need another programming language? I'm not going to be fanatic about it...use anything you think will do the job. But I'm not going to be using a language that gets upset if my indents are a off by a space, and that runs counter to my intuitive perception that white space is syntactically meaningless.
Great men are almost always bad men--Lord Acton's Corollary