Mother of Perl Magzazine
Andy King sent us a fluffy little
statement about
Mother of Perl that I've simplified: Perl
is good. We like it. This biweekly zine will help you know it
better. First article is on XML. This isn't the Perl Journal (which
has a permanent spot in my bathroom) but its not bad.
Update: 02/18 12:20 by CT : course it would be better if the registration worked.
Let me respond, since you raise some good points.
1. TMTOWTDI.
2. Using XML::Parser would be overkill for such
a lightweight format.
3. I guess no one noticed that the headline files
were not well formed to begin with (no root element), hence, it would not work with an XML or SGML parser. I had to deal with the format that was available.
4. Audience - exposing readers to full blown XML concepts would blow most people away unless I started with an XML intro.
5. The article is for the Desparate Perl Hackers out there who need to solve difficult problems efficiently in an imperfect world. This often involves performing unnatural contortions like embedding non-HTML tags in HTML, and working with invalid XML. That's what Perl's good at.
6. The Spring edition of TPJ will satisfy your craving for a pure XML example using XML::Parser.
I will probably be addressing XML further in the future, among other things. Please feel free to send suggestions for a topic you'd like covered.
Jonathan Eisenzopf.
http://www.webreference.com/perl
If you simply want to write a script to prepare a summary of news from a site, you really don't need XML.
If you want to use XML, you should be using the Perl XML packages.
To really program with XML, you need to adapt an event-based model that the XML packages promote. This is reminiscent of OmniMark, an SGML processing language.
The example provided by Mother of Perl is quite lame. The author hasn't really exposed Perl's XML facillities at all.
The article didn't seem to be about querying XML,so I don't think your comment stands on much.
Then let me put a little more directly. You demonstrated nothing intrinsic about XML. If you're not parsing or validating the data structure in any way, you're simply using a tagged format that may or may not be XML. This should be obvious to anyone with any experience with SGML or XML - it doesn't conform to the standard unless you validate it - and the validator is also usually a parser that provides useful state output (like expat).
You haven't demonstrated any proficiency with these common tools or the XML packages, so frankly I don't see where you get off claiming any expertise in the field. I certainly wouldn't waste my money on your book.
By paying someone (active state) to port Perl to Windoze in order to enable IIS to compete with Apache.
same thing with java and C*...
You missed the point. Dylan is as abstract and friendly as the "scripting" languages, but it's a "real" programming language in every respect. Last time I check Perl was not written in Perl, and Python was not written in Python.
A dab of Didi-7 (purportedly) should take care of that spot!
Little Debian: America's #1 Snack Distro!
sub says it all...
Run. I like water. Push My rutabaga.
The Perl Journal belongs in the bathroom because:
a. Perl gives you the runs
b. The PJ makes great toilet paper
c. All of the above
Title says it all. Perl might be cool, but python kicks ass :)
I would disagree... give it a chance - perhaps a bit confusing at first, but I've found it far easier to understand than Perl.
Have a look at: http://www.php.net
PHP vs Perl... perhaps missing the point a bit... what about PHP vs ASP?
Only people with beards (and people who had beards or want beards) like Perl.
Yet another interpreted OO language...but at least the syntax is a little easier to digest.
Perl's syntax is grody, but we seem to all already know it...Python's syntax is grody and far fewer people seem to know it.
Dylan looks even stranger.
Except for its braindead syntax.
m l#6.2
/mill
http://sunsite.auc.dk/www.python.org/doc/FAQ.ht
"Since there are no begin/end brackets there cannot be a disagreement between grouping perceived by the parser and the human reader. I remember long ago seeing a C fragment like this:
if (x = y)
x++;
y--;
z++;
and staring a long time at it wondering why y was being decremented even for x > y... (And I wasn't a C newbie then either.)"
Well the natural and simple solution is of course to not allow statement bodies that aren't enclosed by brackets (something I always do anyway).
"[some crap about saving lines of code with a forced coding style guide]"
I say - get a better editor.
Perl is just too messy when it comes to web development. SysAdmin scripting, yeah, it's better than PHP, but as far as web dev. goes, PHP is tha bomb.
Well from my reading of his posts to the Perl-XML list I know he has the expertise in the field.
/mill
Your credentials are of course unknown when you are just another Anonymous Coward.
APL rules... it's more readable than Perl, and
when was the last time you could do symbolic math in a Perl script????
Long live APL - the god of programming languages!
Python might kick arse, but Dylan really kicks arse. Dylan compilers are written in Dylan.
In Dylan, program flow constructs have a matching 'end' statement.
(The trailing 'if' is optional.)
I guess no women have beards?
heh I've seen perl women with beards (scary)
Well I find large Python programs close to impossible to grok, because of its use of indentation.
:-).
/mill
Python might be a cleaner OO scripting language, but for text processing I rather use Perl. I would use neither for application development (unless they are very small).
Well I will go back to my module writing - Perl of course
Python may be the greatest language ever, but I'll never know because the flagship book is terrible.
(1) If I rewrote the book, I'd take out all the smiley faces. That'd trim 100 pages right there.
(2) The book doesn't even cover how to accept input until like chapter 14??!? Hello, input/output is *fundamental*. I think it's very revealing that the author doesn't cover how to accept input until very late in the game.
Lots of other stuff wrong with the book. But basically, the book is a hurdle most people (like me) will look at and wonder why it's worth clearing.
Are there ANY decent python books?
Well, there was that one issue of the Python Journal that came out a while back, but I'm not sure what the status is at the moment. (On the other hand, setting a deadline for the next issue would mean I'd have to finish my article. Hmm... decisions, decisions.)
But, um... what's XML, and why do I care?
IMNSHO is Python is the best platform right now for developing XML-based solutions. Java comes close, but in the XML arena, Python's solid OO, dynamic programming, and the excellent work done by the Python XML SIG, give it a significant advantage.
I don't think Perl is even in the ball-park. Yes, I know about XML/SGML::Grove, but the Perl community was inexplicably slow to support XML, and is now lagging.
--Uche
Only people without a brain (and people who had brains or want brains) make comments like those above.
Larry kicks Guido's ass anytime, anywhere, and you know it!
I actually read that next part as
"This biweekly zine will help you know better."
Oh, well. Need more caffeine, I guess.
--
Not the same thing though.