Best of The Perl Journal 123
Computer Science & Perl Programming | |
author | Jon Orwant (Editor) |
pages | 710 |
publisher | O'Reilly and Associates |
rating | 8 (7 and 6 for other vols) - Well written, some flaws |
reviewer | Tony Williams |
ISBN | 0596003102 (0596003110 and 0596003129 for other vols) |
summary | Well edited compendium of magazine articles on Perl |
All three volumes reveal a good hand at choosing articles and editing the contributions; after spending three years as a magazine editor I know that not all the contributors could have written this well. The writing is consistently good, tight, well edited and readable.
Across them all you will find articles by almost every major contributor to Perl and a great many of the people who have contributed major modules to CPAN. It's good to feel that perhaps a few cents from your book purchase is flowing into each of these pockets and repaying their work.
Viewing the 3 books as a whole my one real concern is that perhaps a little tighter restrictions on the article choice may have been better -- some of the articles are really only of historical interest, discussing methods overtaken by further development in Perl or the modules available. You may also find only one or two of the volumes contain articles of particular interest to you, I discovered that my favourites were spread across all three and bemoaned the semi-arbitrary division of topics as I only closely read about two books worth from the three volumes -- of course your milage may vary.
The first and largest volume, Computer Science & Perl Programming, is the one volume where I read and enjoyed almost every one of the seventy articles (by 41 different authors) included. The topics covered vary widely, from an essential trilogy of articles about regular expressions by Jeffrey Friedl to some esoteric discussion of Perl internals by Chip Salzenburg.
The second volume, Web, Graphics and Perl/Tk, contains 39 articles, around half of which are devoted to topics such as mod_perl, spidering, and other web stuff. Here is where you can find yourself reading an article about topics now made redundant by changes to Perl and its modules. The graphics section is an eclectic mix while the Perl/Tk section adds up to a fairly good tutorial on the topic.
The third volume, Games, Diversions and Perl Culture, collects 47 articles on a broad range of topics: 15 of them are about various sorts of language processing in Perl that I found extremely interesting. It also includes the Obfuscated Perl Contests, the Poetry Contest and a bunch of other "silliness." An article on how the magazine's covers were photographed seemed particularly pointless.
I'd recommend the first volume for almost anyone interested in Perl. The second might be worth purchasing if you wanted the web coverage. The third is worth it if you want the coverage of language processing or have an interest in the culture that surrounds Perl. Check the O'Reilly pages for one, two and three to see the tables of contents, index, grab the code examples and download a sample chapter (the third volume has two example chapters.) I've given the first volume an 8 but the other two get 7 and 6 respectively as the article choices make them less useful, though the quality of writing and editing is as good.
I think all three would be a marvelous addition to any decent tech library - they seem perfect for a library as they have all the benefits of a five year collection of TPJ without the problems of magazine storage, cataloging and conservation. For everyone else, grab the first one and then decide based on the content for the other two.
You can purchase Best of the Perl Journal (Volume 1, Volume 2, Volume 3) from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Not unlike a real-life journal.... (Score:3, Funny)
Re:Not unlike a real-life journal.... (Score:5, Insightful)
Oh, enough of that already. The bottom line is that a programming language you are unfamiliar with looks like gobbledygook. I suppose you think Chinese and Russian are gobbledygook, too.
Excuse me? (Score:3)
I'm so out of the Perl loop that if I just need to do some text parsing, I'll use AWK every day over Perl. Understand, of course, that Perl is more than just text parsing; its truly the duct-tape of the web...
Excuse you. (Score:2)
Re:Excuse you. (Score:2)
well, only if you are using mod_perl...
I am sorry but if you are disciplined enough to write tight code always, it matters shit little what language you use.
I can't agree. I've had some perl programs that were measly hundreds of lines of code. Strict pragma all the way. A couple of not-so-tricky RegEx's. The kid who "inherited it" couldn't figure it out so the project got shelved.
I see kloc upon kloc of ADA code... and even "Confusing" state machine loop
Re:Excuse you. (Score:1)
Come on, either your code was poorly-written or the "kid" who took over maintenance wasn't competent. That's not intrinsic to the language.
Some people get confused by their own native language. It doesn't mean there's something wrong with Kannada, or Bahasa Indonesia, or
Re:Excuse me? (Score:2)
I'm not a disciplened programmer by any standard, being mostly self-taught, but I can still
Re:Excuse me? (Score:2)
Then maybe you are a better programmer than I was.
I support everything you say in your post- its all true. Perl IS a great general purpose language.
But when I went to knock off a quick script that would take text input and chop things at 80 chars per line and add line numbers, I had a dickens of a time remembering my perl and getting it to work. (it wasn't chopping properly) Without opening a manual I was able knock out a quick awk script to do the same
Re:Excuse me? (Score:2)
Here's a Perl script to do what you want that's not too bad. I left out comments to be fair, but normally even for a tiny program like this I'd include a couple just to remind me what it's supposed to do and for a quick hint of what substr does:
Re:Not unlike a real-life journal.... (Score:1)
Re:Not unlike a real-life journal.... (Score:1)
I can live without synonyms as well - they just make maintenance that much hard. Maintenance isn't just about reading, although that's the step. IMO, the ultimate step is to understand the intentions of the programmer - Perl doesn't make this easy in the slightest and I maintain a number of large perl scripts.
Just as the writers of Perl 6 (where is that, BTW?) are trying to make Perl more like Pyt
um, err... (Score:2)
The problem people have with perl, including myself, is that if you ask 10 perl hackers to do the same task you are going to get back 10 completely different pieces of code.
This can be an incerdible pain in the ass to deal with, espically if you have to maintain somebody elses code when they code in a completely different manner than you do. Consider this...
and
I probably screwed
Re:Not unlike a real-life journal.... (Score:4, Insightful)
However, as someone who just started learning perl, I think it's a great language. Learn a little about the language and then say it's hard to read. Heck, I could put all my c code on one line, does that mean it's a hard to read language?
Re:Not unlike a real-life journal.... (Score:1)
Just a question (Score:5, Interesting)
Re:Just a question (Score:5, Insightful)
I'd skip volume 3 (sounds kinda silly) unless you are a completist. Volume 2 sounds like the most useful and valuable- sure the article on Regular Expressions was GOOD, (I think I only read the first one) and understanding Perl internals would be a bonus, but the code examples of the web stuff is the best bet for my money.
So get (or borrow) Volume 2, if you like, get Volume 1, and if you become a raving perl maniac, have someone get you Vol 3 for a birthday present.
Re:Just a question (Score:1)
Re:Just a question (Score:4, Insightful)
The Camel Book is a great resource, too.
The secret to perl:
In other programming languages, when the compiler can't figure out what you are doing, it cries and gives you a cryptic error message.
In Perl, the compiler narrows it down to a few choices, flips a coin, and goes with one interpretation. Never mind that it wasn't what you intended! Frequent use of debug statements and USE STRICT pragma and USE WARNINGS pragma should help your code.
Re:Just a question (Score:1)
your program should start:
#!/usr/bin/perl -w
use strict;
After that you should receive good error messages. When I look them up in the Camel book I'd say 90% of the time the book explains exactly what I had done wrong.
It's wonderful compared to the horrific error messages and stack trace spam that java gives me.
Re:Just a question (Score:1)
Don't forget the often overlooked "use diagnostics;" either!
And if you're writing CGI's then for testing puposes something like "use CGI::Carp 'fatalsToBrowser';" can be a lifesaver too - but remember to setup something different when your code is in production use.
Re:Just a question (Score:2, Informative)
Add use diagnostics; during development, and you may be able to skip the Camel step in many cases.
Re:Just a question (Score:3, Funny)
#!/usr/bin/perl -w
Then, when that doesn't seem to help, you switch to
#!/usr/bin/ruby -w# :)
Re:Just a question (Score:2)
Hey now, that's the one that has some of my code in it. Of course, I don't make any money off of it, and it's one of the obfuscated code contest 2nd-place entries... but I like knowing it's out there.
Re:Just a question (Score:2, Interesting)
Further, Perl is a language that rewards exploration. You'll discover 20 wrong ways of doing things, and one day you'll settle into one you like for your own
Re:Just a question (Score:2)
I think all your points are completely valid. However for Volume 2 (which appears to be web stuff) its nice to see some code that does it. It gets you up and running. Then later on you can decide if you want to parse everything by hand crafted regular expression pattern matches, or relegate the grunt work to some module you Dl'd off of CPAN.
Between TPJ and the Camel book I had enough to get my hands dirty and start writing some good code. I also lurked
Re:Just a question (Score:1)
The TPJ articles are directed at a more advanced audience. Depending on your programming experience, you should start with "Learning Perl" (less) or "Programming Perl" (more). The latter is a must-have for anyone serious about Perl. If you are more independent-minded, you can also use the perldoc documentation, but although it is very good, it is not as well-structured as, say, the PHP manual.
Re:Just a question (Score:2)
Damn CMP (Score:5, Interesting)
Re:Damn CMP (Score:3, Funny)
Re:Damn CMP (Score:5, Informative)
Re:Damn CMP (Score:2)
Remember kids, if you could fit 12 issues of Byte on your magazine shelf, you're not reading the golden age of Byte. :)
Would have been much more readable... (Score:4, Funny)
Re:Would have been much more readable... (Score:2)
Whew. That's only about half of it. But you get the idea. This was a feature article, too... a real barn burner.
Re:No punctuation or spaces? (Score:1, Offtopic)
I bet these moderators are shocked and offended by a Jay Leno monologue.
Re:No punctuation or spaces? (Score:1, Offtopic)
It's funny!
If it needs to be explained to you, maybe you shouldn't have mod points on slashdot.
Re:Would have been much more readable... (Score:2)
&duh();
Re:Perl's motto should be (Score:2)
Well, I, for one, think you are funny. You probably got scored a zero on account of posting anonymously.
Editors assume they are better than mods. (Score:1, Offtopic)
Just curious, seems this happens at least once every few months.
poster-sized cover prints? (Score:1)
I'd particularly like the one where someone attempts to compile perl on a typewriter.. (underwood? I can't find it in a GIS..)
I think I will get it (Score:1)
Reading perl is almost as much fun as writing it. In it's more 'condensed' styles it is much more challenging (read: fun) to decode than java and the 'tmtowtdi' ethos sparks a lot of creative architectures.
For me learning perl was/is more fun than any other language I have tried, those docs can be hilarious. They also help keep your spirits up during
But the real question is... (Score:1)
Re:italics tag? (Score:1)
Re:Not to be confused with... (Score:1)
Re:Not to be confused with... (Score:1)
Re:Best of Perl? (Score:4, Interesting)
Perl encourages people to write very compact, easily readable code in perl. Ofcourse, some familiarity with basic syntax is needed. However, many people write code in perl just like they are writing AWK or C code.
Just to contrast, have you seen any C++ code generated by Visual Studio? How would that code look to someone not familiar with the environment?
Here is a cut down example of easy to understand code from the CGI page... well, lameness filter is complaining too much. Anyway, if you do perldoc CGI, you will see how it looks.
S
Re:Best of Perl? (Score:1, Troll)
Re:Best of Perl? (Score:2)
Just to contrast, have you seen any C++ code generated by Visual Studio? How would that code look to someone not familiar with the environment?
Ah yes, being familiar with the environment would help but it is still awful obtuse.
I always thought Perl got a bad rap for encouraging bad hard to read style.
I have worked with old C code so badly written that it was a nightmare to figure it out. It used massive global data via nested (and redundant) includes files. The original authors relied heavily on comm
Re:Best of Perl? (Score:3, Insightful)
Consequently, people get stuck with a very limited set of tools in the language, and (many are stuck in the perl4 syntax I believe), and write code accordingly. To a newcomer that reads such code, it becomes a nightmare.
I found Visual Basic code written by someone very complicated. Turns out that the code was written in a very adhoc manner. Not being familiar wi
Re:Best of Perl? (Score:2)
Yes, of course there are individuals who code in all kinds of languages who write poor code. I was merely making a shallow generalization based on personal experience. Hey, it's slashdot, why not? :)
Re:Best of Perl? (Score:2)
Look at this cryptic code:
open(FILE, "/etc/passwd");
while($line = <FILE>)
{
print $line;
}
close(FILE);
Re:Best of Perl? (Score:2)
Highlights how not to write Perl code since there's no bang line, strict pragma or scope controls and the grandparent is relying on the obtuse open() call rather than using the FileHandle module which would've been much cleaner.
Oh uh... and it does exactly what he thinks it does all the same, except for the last line may or may not print out. Ah, the power of Perl, TMTOWTDI:
Re:Best of Perl? (Score:1)
Heh.. yeah, but if you wrap a single system call in a Perl or shell script, you should be shot.
Re:Best of Perl? (Score:1)
Re:Best of Perl? (Score:1)
That looks more cryptic that it needs to be.
Re:Best of Perl? (Score:1)
I call shenanigans! File::Slurp is not a standard module! Cheater! Cheater! :p
Re:Best of Perl? (Score:2)
Most of the additional time is the loading of the module. Watch:
$ time perl -e 'use FileHandle;'
real 0m0.102s
user 0m0.083s
sys 0m0.016s
$ tim
Re:Best of Perl? (Score:1)
NOOOOOOOO! (Score:2)
#relax I'm just being a picky Perl person
#I could be Christiansen and call you a godless moron
use strict;
open(FILE, "/etc/passwd) or die $!, "\n";
while(<FILE>) {
print $_;
}
close(FILE);
exit;
Re:NOOOOOOOO! (Score:1)
Re:NOOOOOOOO! (Score:2)
Re:NOOOOOOOO! (Score:2)
Re:NOOOOOOOO! (Score:2)
Re:NOOOOOOOO! (Score:2)
You're absolutely right. If you did this:
while () {
$line = $_;
print $line;
}
That would be wasteful. Not to mention stupid. You would do this:
while ($line = ) {
print $line;
}
Which doesn't involve the implicit variable at all. Clearer, easier to read, no less efficient... what's the problem?
Re:NOOOOOOOO! (Score:2)
Re:NOOOOOOOO! (Score:2)
Re:NOOOOOOOO! (Score:1)
open(FILE, "/etc/passwd) or die $!, "\n";
while() {
print;
}
close(FILE);
exit;
Or is that bad form?
Re:Best of Perl? (Score:1)
Re:Best of Perl? (Score:1)