Slashdot Mirror
Perl and XML
With qualities like these, one might think that the marriage of Perl and XML would be total bliss, and the two languages would live happily ever after. In reality, however, the marriage has been far from perfect, and has produced an enormous number of kids: some uglier, some prettier, some simpler, some more sophisticated. Perl & XML is a good attempt to provide an overview of XML processing techniques existing nowadays in the Perl world.
The book does not even make an attempt to give you a brief introduction to Perl, and thus eliminates the weak point of trying to be another Camel book, as many publications in the field attempt to do. The logical assumption is that you know Perl and have heard something about XML. The first chapter of the book tells you why there are so many variations of Perl modules for XML processing, who is behind the well-known modules and why the interaction of Perl with XML has been rather disorganized. Indeed, a short visit to the XML section of CPAN brings up dozens of available modules, most of which characterized by some intimidating or non-descriptive names like SAX, Grove, YAWriter, etc.
The second chapter is titled "XML Recap"; the contents of the chapter, though, are good enough to be called "Concise but Informative Introduction to XML". Don't get your expectations too high -- O'Reilly has a whole bundle of books related just to learning XML, and thus a single chapter can barely touch the surface of what you might need to know, but it provides a good introduction to the world of markup, elements, namespaces, character encoding, processing instructions, schemas and transformations in XML.
Chapter 3 goes from theory to practice, and gives the reader an opportunity to try his first Perl script on XML data. The parsers covered in this chapter are XML::Parser, XML::LibXML, XML::XPath and XML::Writer. Document validation and well-formedness are also explained, and luckily enough this exact chapter is what O'Reilly Publishing decided to publish as a free chapter available on the Web. In this chapter, the authors make a distinction between stream-based and tree-based XML processing, and thus it doesn't come as a big surprise that the next four chapters are dedicated to examples of such processing.
Chapter 4, Event Streams, discusses the issues of processing XML document as a stream of data, where your application has to react to various input without really knowing where the end of the document is. XML::PYX and XML::Parser are covered in this chapter.
Chapter 5 shows examples of using SAX for XML processing with Perl, and also provides an overview of SAX history, which in a nutshell tells you that SAX has been designed for Java with its strong type checking and interface classes. It goes to explain that using it in Perl, which is known for its forgiving nature, thus requires a certain responsibility on the part of programmer. XML::Handler::YAWriter is also discussed in this chapter.
From stream processing, the authors take you to parsing XML trees. In this case, the document is assumed to be loaded into memory and Perl script can safely assume that the whole XML document has been loaded. XML::Simple, XML::SimpleObject, XML::TreeBuilder and XML::Grove are discussed in this chapter, with XML::Parser revisited.
DOM (Document Object Model) is another standard recommended by W3C and it is mostly concerned with how an XML document is stored in computer's memory. XML::DOM is discussed in this chapter with XML::LibXML revisited. The authors also provide a good overview of DOM standard.
The last three chapters deal with applications of Perl in XML data processing that go beyond stream and tree processing -- XPath and XSLT are explained with copious examples. Remember though, that both technologies have several-hundred-page books written about them, and thus several pages in a Perl and XML book can serve at best as good introduction. Chapter 9 deals with RSS and writing SOAP with Perl and XML, with XML::RSS and SOAP::Lite being explained. The last chapter deals with such issues as namespacing, subclassing and for Web designers provides a handy tutorial on converting your XML data into HTML via XSLT stylesheets.
The table of contents is posted on the publisher's Web site.
The first three chapters of the book are easy to read, since they provide a general overview of the data-processing world, history of XML with reference to appropriate events in the Perl community. However, data processing can hardly be called an exciting topic and thus bulk of the book is about routinely introducing particular modules, telling you what you can do with each, and then giving you an example of Perl code processing some XML document. The examples are apt and relate to some of data processing that some us had to do, i.e. shopping lists, address books, recipes, diaries of mad professors, etc.
The code examples are numerous, and if you get tired after looking at pages and pages of Perl lines, you better plan accordingly, as sometimes the subchapter consists of nothing more than an XML file and related Perl processing code with author's notes. For a 200-page book Perl and XML provides a great introduction into the area, provided you have good knowledge of Perl, using CPAN modules and just general knowledge about data processing. The book would probably have a more exact title if it had the word "Cookbook" in its name -- some might consider it a good reference. However, for those just getting acquainted with XML, another tutorial might be needed to get a full comprehension of XML's power.
You can purchase Perl & XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Review of the same book from a little over a month ago...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
The same book was reviewed by slashdot over a month ago? NAAHHHHH!!!
It's so good, it gets two reviews!
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
I thought Perl's name suggested that it was good at being pathologically eclectic and rubbish listing.
Is this book anything like this book with the same name and authors. This one's published by O'Reilly, the other was published by some group called O'Reilly and Associates. Hmmm maybe that's the difference.
.NET all the way... can spray paint your car on demand! HOW ABOUT THAT! the age we live in. :o
Perl is hell only for those people that are truely poor project managers that don't know how to develop a good coding standard .... go play with Visual C++ and let the REAL programmers be happy.
HallmarkOrnaments.Com
I agree fully, I have also read the book and come to the same conclusions. Perl is good for writing quick and dirty scripts but is not suited for a real site.
Personally I am more impressed with microsofts script language, called batch processing (.bat files) and I would like to see this used more for internet applications.
This review is "Perl and XML". The other review was "Perl & XML". Big difference.
Well, the code is more or less unreadable by anyone except the guy that wrote it, so yeah, I guess it would be a great language to use for a group project.
Finally, math books without any of that base 6 crap in them.
Where the hell have you been? Everyone knows real programmers use PowerBuilder.
(* Perl is fine for single developer, heavenly might some say. But for team projects it's hell in disguise. *)
:-)
Perl developer's are so productive that you don't need teams
Seriously, I have come to the conclusion that languages are pretty much subjective when it comes to productivity, error rates, etc.
While I am not a Perl fan myself, if Perl fans are productive under it, then I have no reason to complain, as long as they don't shove it down non-fan throats (like some Sun technologies).
Table-ized A.I.
The same argument best used in favor of MySQL applies here as well: not everything has to be a super scalable, completely buzzword compliant, ninth-wonder-of-the-world engineering project. In fact, I'd wager that if you counted up all "developer time" spent in the US every day, you'd find that a large percentage of it is done on "throwaway" projects.
Lots of people just need to regex through logs and make a simple database and draw quick-and-dirty graphs and walk a MIB on a router and automate a build process and probe a firewall and so on and so on. They use perl, shell, whatever. And that's completely fine. Whatever works, works.
And XML, as he notes, it bloated by ivory-tower academic requirements and has made (and will make) zero headway in the Real World.
You couldn't be more wrong. XML couldn't be more real world. SOAP, office doc file formats, database output, jabber, web services, config files, the list goes on. Even nmap spits out XML if you want it to. Hell, we've been fighting to get it used at the university where I work because we've used it in the "real world" and know and like it...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Does XML make Perl obsolete or Perl makes XML obsolete.
Je t'aime Stéphanie
So, will PERL programs will now be able to be written in XML and appear more logical and well-structured???
Its a shame, because Jason McIntosh can write well and he is a decent coder. But he moved out of the apartment 3 months ago and we still find stuff of his lying around.
Jason, please come by and pick up your "Infocom's greatest hits" and your various Mac
connector cables. The lease is up soon. yadda yadda nag nag nag.
why don't you go play some brainfuck golf and come back and tell us that again? Some languages are more productive than others, some are faster than others, and some are safer than others. Brainfuck happens to be increadibly slow to develop, runs slow, and has no mechanisms for detecting or dealing with errors whatsoever. And that is why I love it ;)
...and this lie crawls out of its mouth: 'I, the state, am the people.'
www.cgisecurity.com/lib
agreed. We've recently started using XML for internal things, and I must say it is quite impressive, and has so many applications in the 'Real World.'
It's also dumb to have any introductory XML material if you're not going to be serious about it. Which gives me an excuse to plug my favorite XML for beginners book, Harold's XML Bible, 2nd edition. Yeah, stupid title (who are you, Moses?), and the CD-ROM is badly put together (you'll need to convert some text files from Mac format!). But the book itself is very good. No assumptions at all about previous knowledge If you know jack about XML, or you understand the basics, but can't figure out how it's used, this is the book you want.
When did /. switch to publishing in Win-1252 charset? I hate to see those ?s everywhere. Not everyone is using IE.
So, Perl is optimized for quick and dirty problems. The kind in which you know in advance you won't be maintaining it, and don't need a solid, easily-maintained language.
And XML is a sophisticated mechanism for describing data for when a simple pipe-delimited file format won't achieve a sufficient buzzword high. It's so powerful that this book doesn't even go into detail on learning XML - the reviewer recommends additional books for really getting to understand XML, should you desire to replac the fast & easy delimited format.
Oh yeah, sounds like a match made in heaven.
(* Some languages are more productive than others, some are faster than others, and some are safer than others. *)
Well, toy languages aside, their tradeoffs tend to counter other things. For example, dynamic languages might not check as much at compile time, but the tradeoff is that the language may be simpler and easier to read and test and combine easier with parts from "outside the type tree".
I don't want to get into another long "my language is better than yours" debate, because they never go anywhere.
There is at least as much evidence that letting people use the language they are more comfortable with increases productivity as there is that there is "one best language".
Table-ized A.I.
The author correctly points out that Perl is best suited for quick, unmaintainable hacks and not serious, large-scale engineering.
A common misconception about Perl, and I understand why you would think this way. Having written several large systems in Perl (as well as several smaller systems in which maintainability was key), I will point out these problems with your thesis:
1. If your quick hacks are unmaintainable, get another job. If your prototypes aren't good enough to turn into a product with a small amount of work, you're wasting lots of your own (presumably valued) time.
2. PDL belies your comments. Take a look at it. It's large, maintainable and certainly serious. Scientific computing is a dream with it.
I generally find that "large scale engineering" is the easy part. What's hard is applying sound engineering and scientific principles to your code. You can do that as easily in C as in Perl as in Python as in Eiffel. It's a little harder in C++, though honestly not by much, because of the action-at-a-distance nature of C++'s object model.
Oddly, Java has a problem in neither area. Java's problems have very little to do with the language itself (which is an acceptable C derivative, if you want a C derivative with GC) and more to do with what Sun does with it, and how that has trained its users to approach it.
Perl's biggest problems are the following:
1. Incomplete object model. This was deliberate, and has given Perl6 the ability to form its object model out of a decade of best practices by those who "rolled their own" in Perl5.
2. Circa AWK/shell subroutine semantics. Also a major aim of the Perl6 effort, this is a subtle thorn in Perl's side. It's easily overcome once you get used to it, but leads to nearly impossible-to-optimize function calls in average code.
3. The lack of true compilation of the language leaves software developers with very few options in terms of shipping programs. Again one of the first aims of Perl6
See the Perl6 theme? Wait for it... it will rock your world.
Q: "What do these three fine legislators have in common?"
A: They all belong to a party representing a diverse constituency.
I don't like these guys on tech issues, but then the Democratic party has never had a united front or a singular coherent social or economic agenda.
If that's what you're looking for, go with the homogeneic party that represents wealthy (or at least selfish), christian, socially conservative white people. Fortunately for favored Republican constituencies, there are a lot of *voters* in America who meet that narrow criteria.
Some languages are more productive than others, some are faster than others, and some are safer than others.
Damn it. You forgot to say pick two.
~~ What's stopping you?
Or rather get another language. It's not difficult to guess that it should be Python.
You cannot hack on Java - you change the task requirements to fit all the limitation, restrictions of the language and of proprietary frameworks. Your hacks on Ruby will be very limited and immature. Your Tcl hacks will be same unmaintainable with a grown project size, although at least you will be able to read your code.
OCaml, Haskell, Oz and Erlang are still too exotic for Linux/BSD world. Although, when I've tried them I've got a real and fresh entertainment. However, there is a real lack of good libraries. Lisp and Scheme have the same problem.
Conclusion: writing over-obfuscated code was not in the job requirements. Pick the right tool for your job.
Less is more !
Show me use cases, styles, patterns and examples of developing web applications with AxKit. Same about Redland, which suffers from the lack of documentation.
This book just repeats about XML what was already said in other books.
Less is more !
Perl is easier to read than C or C++ because it is dynamic?!?!
Give me a break. My worst nightmares have all been forgotten perl projects i inherited from other developers. Who wrote a wonderful program in half an hour, and took me 3 days to understand what was going on. And i'm no amateur.
Perl is THE most used obfuscation language out there.
Your definition of "quick hack" seems to be questionable. I've cranked out quick hacks in every language I've ever used (C, C++, Perl, Pascal, CLIPS, numerous line-oriented scripting languages, LISP, etc.) It's always possible, and downright good. What's bad is writing code for any reason which others cannot understand and manage. If you do so in Perl, it's just as bad as doing so in Java, Python, C or COBOL.
Every language can be used to write obfuscated code. The question is, do you write obfuscated code for fun and when appropriate, or do you do it because you cannot do otherwise? If you cannot do otherwise, get out of the kitchen. If you can, do... in Perl or whatever langauge suits the job at hand.
Perl simply suits more jobs than most languages because of its flexibility, from complex data management (yes, of which its heralded capacity for text processing is a minor and rather unimpressive aspect) to elegant implementations of such high-level constructs as closures to the grace with which it does what you probably wanted in the first place by default, but always offers you the option to do otherwise.
Your comments make it pretty clear that you either do not know Perl, or you do not know it well. This is not shocking. Most people "know Perl" because they've seen some overglorified mailroom clerk's attempt at text processing written in it. The fact that Perl lends itself to being used by low-end programmers does not mean that that is the only domain in which it functions. If it were, I would have moved on long ago.
(* Perl is easier to read than C or C++ because it is dynamic?!?! *)
Maybe for a Perl fan it is. (Plus, Perl is not the only way to make a dynamic language and there are exceptions.)
Like I said, different people are suited for different languages. Perl models Larry Wall's head, and people who think kikd of like Larry like Perl and can read Perl.
Table-ized A.I.
So is yours.
Every language can be used to write obfuscated code.
Here we go. I hack (and have a pleasure from it) in order to "crack" the puzzling problem and to reduce the overall obfuscation in the environment around me. Think about enthropy. You increase disoreder by writing an obfuscated code when it is not originally required. You do it for "fun" - you receive a pleasure when other people are suffering looking at your code or trying to fix it. So, you should go out off the kitchen as you make a life of other people harder. You are a cyber-punk.
The rest of your comments, both about me and about Perl is just a troll and thus should be ignored.
Less is more !
Juiz de Fora IRC fotos
You increase disoreder by writing an obfuscated code when it is not originally required.
No, I most certainly do not. I don't know how you got that impression, but you're wrong. As I alluded to (perhaps too causally), I do obfuscate code for fun in competitions such as the IOCCC, but when it comes to work, I consider obfuscation to be downright evil. Anyone who writes hard-to-read code in Perl, C, C++, Java, Python, Eiffel, LISP or any other language should be shown the door. It's simply not acceptable.
I think you and I agree on this point, so I'm not quite sure how we got on opposite sides of the debate. I guess you just assumed that because a lot of lousy programmers have used Perl, that Perl is a language only suited to lousy programmers. That is certainly not true.
Now let's get back to Perl. My point is that even programmers experienced in several programming languages, well CS educated and having years of successfull experience, they have problems of reading their own code in Perl after awhile. I can speak for myself and for several others. We can write quickly well working programs, but with increasing of the code size the ability to read and understand the progam is declining. Thus, we call Perl as a "self-obfuscated" language. Even having some general comments in the text it's hard to read. The reason I see is in regexps and awk roots.
Other languages used to compare a capability of self-obfuscation: Python, Tcl, C, C++, Java, Lisp, Scheme, Prolog, Oz, Haskell, Erlang, OCaml.
Personally, I have the best result with Lisp, Scheme, Prolog and Oz, when I can unnderstand the code after years and I can easily read the code of other programmers without "over-comments". I can do even "eye-debugging", running ever the code back and forth and predicting without mistakes what's going on. The reading such text is like reading some English text. And the writing is like the rythming of poetry.
Good results I have with: Python, Java, Haskell, OCaml and Erlang. The reading reminds me XML and RDF. The writing is like the compocing an article or a book.
Bad results - with C, C++, Tcl. The reading reminds me TeX. The writing is like creating a legal or medical document.
The worst result - with Perl. I can compare it only with Postscript and m4. The writing is like you to it blind - you cannot read.
Less is more !
I wonder if this book was ever reviewed before??? Its strange to think that more than one person would want to review the same book. Theres gotta be patent laws against that or something. Right?